today's a big one. We're going to learn how to solve a problem that literally every robot has, and that's control. You see, if your robot isn't taking some kind of input, doing some magic, and using it to control some actuators, whether it's Motors, Hydraulics, or something else, then it's not really a robot, is it? There are so many different kinds of actuators and interfaces out there, and so many different control methodologies that we use to solve problems with them. But within this huge Universe of options, there's actually quite a lot of commonality. And unless we have some kind of standardized system, if we're just writing custom controllers and drivers every time we start a new project, then we end up rewriting things and wasting lots of time solving problems that people have solved many, many times before. Instead, what we want is a framework where we can write the drivers for all the different Hardware platforms out there, and the algorithms for the different control methodologies, and how they speak a Common Language, so we can pick and choose whatever we need to.

solve a particular problem. You might think that this is a problem well suited to ROS topics. You just write some nodes, be a hardware driver, some of your controllers have some standard messages between them, and bam, you're done. That's pretty much what I did for the motor demo video. There's a few problems with this, but the biggest one is that we need these to be fast. Now, ROS topics are pretty fast, but we want this to be really fast. There should be no delay between the controller and the hardware interface, and that is where ROS 2 control comes in. ROS 2 control is a powerful and a complex beast. So, to understand it, we're going to have to take it step by step. It can be a bit tricky to go from the concepts to using it in practice, so I'll try not to move too fast. And at some point, it might be tempting to just give up and say, Oh, it'd be quicker for me to write this myself from scratch. And maybe it would, probably not. But the value of ROS 2 control lies not in just making a

single project easier even though it often does, but it means that you can reuse code. You can upgrade and modify your system down the track so much easier. It's definitely worth it. So in this video, we're going to look at the concepts of Rust 2 control, and we're going to get it up and going in a Gazebo simulation. And then in the next video, we're going to get it going on this real robot so that we can drive it around. At the center of it all, we have something called the controller manager. It's going to find all these bits of code for our drivers and our controllers and link them together to achieve this. It uses a plug-in system, so each of these little things isn't running its own executable. It's just a library that is loaded up at runtime by the controller manager, and it's got a set of functions that link into the system. Let's take a look at the hardware side first. Different hardware is naturally going to be controlled differently. You might have two very similar-looking

robots. But one's Motors are controlled by a Serial, and the other one via can bus. One might let you control speed and position. One might let you control torque. One might have a single comms interface for all the motors. One might have a separate interface per motor. To use ROS2 control with your Hardware, the first thing you're going to need is a hardware interface. That's a little bit of code that speaks to the hardware and exposes it in the ROS2 control standard way. Ideally, if you've purchased a robot, then the designer of the robot will provide this for you. Otherwise, you might have to search for it online or write it yourself. If you've been following along with my build series, then you'll be able to use the one that I've written for this robot. Otherwise, like I said, you might have to write it yourself, but that's well outside the scope of this video. All we really need to understand is the way that it represents our hardware, and that's through command interfaces and state interfaces. Command interfaces are

things that we can control on the robot. Where State interfaces are things that we can only monitor. So, for example, with my robot here that I've been building, you might remember that the motors we can only control the velocity. So, that would be a command interface. But we're also able to measure the position with the encoders, as well as the velocity. So, the position and the velocity are going to be State interfaces. So, for this robot, I'll have two command interfaces, one for the velocity of each wheel, and four state interfaces for the position and the velocity of each wheel. If I had other things to measure like the torque or the current of the motors, then these could also be State interfaces. Here's a preview of what we'll see later on. With my Hardware interface loaded, we can see that there's the two command interfaces and the four state interfaces. And at this level of abstraction, there's really no understanding of what the robot is. This could be a differential Drive robot or it could be a robot arm that only has two joints that are for.

some reason, only velocity-controlled Ross 2 control doesn't know, doesn't care. All it knows about are these six interfaces and one robot might have multiple Hardware interfaces. Each of which can have multiple command and state interfaces. This could be because you've got a robot arm mounted on the mobile base, each with separate motor control systems, or it could be because each of your Motors is fully independently controlled and you want them to have their own drivers. To deal with this, the controller manager uses something called the resource manager, which gathers up all the different Hardware interfaces and exposes them together so that the controllers just see a big list of command and state interfaces. And how does the controller manager, or really the resource manager, know about these Hardware interfaces? Because it's tied so closely to the hardware of the robot. We put it into the urdf using a ros2 control tag. We look at this in more detail later, but you can see here that it tells Ross to control the name of the hardware interface plugin to load and also which joints of the uidf it's going.

to be talking to. So that's the hardware interfaces, but what about the controllers? Controllers are the way that we interact with ROS2 control. So on the one end, they're going to be listening for an input on a ROS topic. That could be something like joint positions in a robot arm or a mobile robot body velocities. They're going to take this input, they're going to calculate what the appropriate motor positions and speeds and that sort of thing are, and then they're going to send these to the hardware interfaces that have been exposed by the resource manager. Well, the hardware interfaces need to be designed specifically for individual hardware. The controllers are going to be designed specifically for different robot applications, and since there are a few pretty common applications, the ROS2 controllers package provides controllers that should cover most people's needs. You can always write your own ones if you need to, though. Since I'm building a differential drive robot, I'll be using the diff drive controller. But say you've got a robot arm or something else, then you might need to use one of the other controllers.

so here, the controller manager's job is to take the controllers that it's been asked to load and match them up with the right command and state interfaces that the resource manager is exposing. To set up the controllers, we write a YAML file with the various parameters we need and pass that into the controller manager. From there, we can tell it to start and stop the controllers as needed. Just like we can have multiple hardware interfaces in one robot, we can also have multiple controllers in one robot as long as they both don't want to claim the same resources. They're not trying to command the same interface. They can share state interfaces though since they're read-only. Also, a slightly confusing point is that controllers don't actually need to control anything. At their core, they're just a way for ROS to communicate with the hardware. And that can be as an input, an output, or both. So, for example, say you did have a motor that gives you current feedback as a state interface, then you could use a controller that just reads that and publishes it out to a ROS topic.

okay, we've got our Hardware interfaces on the one side, our controllers on the other side. How do we run this thing? Well, there are two different kinds of ways that we can run a controller manager. Firstly, we can write our own node and have a controller manager running inside that. Well, secondly, we can just use a node that's provided for us. Usually, that's what you want to do, but either way, you're going to need to provide it the information about the hardware interfaces, usually via UIDF, and the information about the controllers, usually via a YAML file. Either way, once the controller manager is up and running, we want a way to interact with it so that we can check the hardware interfaces and start and stop the controllers, that sort of thing. There's a few different ways we can do this. The controller manager has some services that we can call to access this functionality. There's also the ROS2 control command line tool that makes these service calls a little bit easier, and there are also some nodes that handle some of those key functions.

we can run there are different circumstances and pros and cons where we'll use each of these methods, and we'll discuss that later when we use them. That's the theory. Let's put it into practice by upgrading our gazebo simulation to use ros2 control. We'll start by installing a few packages. So, pseudo app install Ross foxy ros2 control Ross foxy Ross 2 controllers and Ross foxy gazebo Rost 2 control. Now let's update our urdf file. I'll be continuing the example urdf that I've been building throughout this tutorial series, but if you're just joining in, this one it should be fine to follow along. So you might remember in an earlier video we created this file gazebo controller exactro, and that contained the information for our gazebo control. Instead, we're going to replace this one with ros2 control. So I'm going to copy and paste it and rename it ros2 control, and we'll get rid of the Gazebo stuff from inside it. And then back in our main uidf we're

going to here where we were including the Gazebo control before. Let's comment that one out, and we'll replace it with our ros2 control. I'm going to leave the Gazebo control one there just in case we ever want to come back to it, but for now, we'll swap to ros2 control. Now the first thing we're going to need in here is a ros2 control tag, and then inside that, we need a name, and we can just call it whatever. I'll call it gazebo system, and the type is system. We usually, there are a few different types out there, we usually want system. Inside here, we're going to have a hardware tag, and then inside that, there's going to be a plug-in tag, and then the plug-in tag is going to have the name of the plugin that we're going to use. This is a piece of code that's been installed separately and registered with Ros that tells it how to talk to the Gazebo simulation, just like it's talking to real Hardware.

so in this case, the name of the plugin we want to use is gazebo rost2 control slash gazebo system. Now, we also need to tell it about the different joints that it's going to be controlling. So here, we're going to put a joint tag and we're going to say the name of the joint, which is our left wheel joint that just came from our robot urdf. You can see here left wheel joint. And then the interfaces we're going to have. So we're going to have a command interface that is velocity, oh, and then State interface for velocity, and a state interface for the position. We can also set limits for our Command interface. So we'll set param name. So we'll set up, we'll set the minimum to I don't know something. It's a bit arbitrary at the moment. We can make it something correct later. And that's it. Then let's copy and paste that for our right wheel. Cool. So we've got two joints we can control. We can control the velocity of each of them through a command interface.

and we can get the velocity and the position of them back through a state interface. So that's the ros2 control tag done. Now we need to add the Gazebo plug-in. This is different to this plug-in. This is the Gazebo plug-in that tells gazebo to use ros2 control, whereas this was the hardware interface for the controller manager. So we're going to have a look at this one. We can see here we had the Gazebo diff Drive plug-in before. So I'm just going to copy and paste that just kind of to show that it's very similar. Oops, and what have I done there? Now the name of this plugin is gazebo oh we. This is what we want to call it. So it doesn't really matter. I can call it gazebo rust 2 control, but the file name is lib gazebo ross2 control. Sorry, my camera overheated there. So we were just setting up the Gazebo roster control plug-in. And this plugin actually does a whole lot of things for

us it sets up a bunch of things on the Gazebo end, and it actually contains its own controller manager, so we don't need to start our own one. Now, that controller manager is able to get the URDF already through the robot State publisher, but it will need to know where our controller YAML is, so I'm going to set up a parameter. Parameters and here we're going to put in the path to our controller YAML, but we haven't written that yet, so let's do that. I'm going to create a new file here called my controllers.yaml, and this is a standard ROS params file if you're familiar with them. So in this one, our node is going to be the controller manager, and in there we're going to have the ROS __ parameters note that that's two underscores. Now what parameters are we going to have? It's going to have an update rate, which we'll put at 30 Hertz. We've got the use sim time. We'll come back to this one later, but because we're running Gazebo, we need to set use sim.

time to true. Then what we need to do is set up our actual controllers that we're going to have here. Now, it's a bit funny the way we do this. We name the controller, and then we give it a type. So we're going to need a DifferentialDrive controller. So I'll call mine diff conch just as a shortcut. And then we need to set the type. And the type for this one is diffDriveController with underscores / diffDriveController in camel case. So that's the DifferentialDrive controller. We're also going to have something called a JointState broadcaster. Now, this is a controller that doesn't control anything, but you might remember that RobotState publisher needs the JointStates topic to be published in order for it to get the wheel transforms correct. It's not really important in the long run for how we run the thing for this particular kind of robot, but it's good to have. And so we'll do a we'll call it joint Broad and the top is jointStateBroadcaster. Now we can actually set up the

parameters for those individual controllers. I'm going to just copy and paste that from somewhere else so you can see here. We've got the differential controller and its parameters, which we'll look at in a sec. There's also the joint State broadcaster. We don't have any parameters to set for it. There are some you can set, but I'm just going to leave that commented out. Now, these are all the different parameters that you can set for the joint State for the differential Drive controller. We're not going to worry about most of them. We're just going to look at these few. So, we've got the publish rate. That's how fast it's going to publish the transforms and stuff at. We'll put that at 50. The base frame ID is set to base link, which you might remember from our robot. We've got the base link there. Oh, there it is. What else do we have here? Left and right wheel names, as we saw before, we told the harbor interface. Now we've got to tell the controller so that

it can marry those two things up, then we've got the wheel separation and the wheel radius. So if we go here, my wheels are at 0.175 away from the center line. So if we fire up the calculator and go 0.175 times two, sweep, our separation is 0.35, and our wheel radius, you can see, there is 0.05. So we've got those set correctly. This last one, use stamped valve, this is pretty specific to differential drive robots, and I'm going to dig into it in deeper in a future tutorial. This depends on whether the input has a time stamp associated with it or not. For now, we're going to set this to false, and we'll deal with that in a later tutorial. So that's all we're going to worry about for now. There's all these other parameters, but we'll just ignore them. You can play around with them if you need to. Now back in here in our ROS2 control, we want to tillot the path to this file, and we can actually use a little trick to

tell it where the package is so we so find. And then my package is called Tiki Bar one. You can it's whatever yours is going to be called slash config slash my controllers.yaml. So that's going to tell the Gazebo Rost 2 control node that when it fires up its controller manager to go and find that file in that package, which is going to be this one and load that up for its controller information. Oh, one quick thing. You might be wondering why I have set used Sim time here but not here. It'll actually automatically propagate the Sim time from the controller manager down to the controllers. So you only need to set it at the top level, not in the lower ones. So let's give this a go. We can get into our Dev workspace and build. Remember to Source our installation. And then we can launch our Sim like we have in the past. And we'll notice that gazebo's got a few extra things that it's printing out here. Things like starting gazebo roster control plug-in. This is a good chance.

for us to start interacting with ROS2 control, so we can type ROS2 control lists. Hardware interfaces. And hopefully, we'll see that we've got our two command interfaces. They've been unclaimed. There's no controller on them yet, and the state interfaces. It'll be tempting to type ROS2 control list controllers now, but this seems to only list controllers that are actually running, not ones that could be started, which is a bit annoying. So now let's start our controllers. Like I said before, there's a few different ways you can do it with services and the ROS2 control command. The way I'm going to do it is with the spawner script, and that's for two reasons. One, it works nicer in a launch file, which we'll be using later on. And secondly, it works the same in Foxy and newer versions, which the other ones are a bit different between Foxy and the newer ones. So for that one, it's going to be in ROS2. ROS2 run the package is the controller manager package, and the script is called spawner.py.

then the name of the controller what we call it diff can't great configured and started difficult and then our other one was giant Broad and then back in this one we should see oh that's a bit odd so we can see here it configured the controllers. Uh it's setting the Sim time to true on the lower ones. Robot State publisher is not very happy about something so we'll have to take a bit of a look at that in a minute but let's try and run our tally up so uh remember normally we type teleop twist keyboard like this and then we go to drive but we'll find that that should be doing nothing and that's because if we type Ross to topic list it's actually listening for it not on the command vowel topic that this is publishing on but at diff count command Val unstamped. Sorry the camera overheated again but I was also getting some really weird behavior on here and it turned out I was still running Ross on my other computer in the house and the two systems were

seeing each other and interacting so just a warning always watch out for that anyway. I've stopped that now. What I was saying was that the controller is expecting the command velocity to be on diff count command Val unstamped rather than just CMD Vel. So when we run teleop twist keyboard, we actually need to remap the topic from command Val up to uh diff can't command Bell unstamped. And hopefully once we do that, we should be able to drive it around just like we could before. And of course, we can start RVs like normal. We can swap to Odom, add our TF and our robot model. And of course, as we drive it around in here, we should be seeing this update. And that should of course be matching what's ah we run up against it thing. Now one other thing that we want to do to make this a little bit easier is rather than having to run that spawner command every time after we do it, we want that to happen automatically. So we're going to go into our launch Sim.

here and after we spawn the robot, we're going to add a new node here. So, diff Drive spawner. It's just running that controller manager spawner.pi with the difficult argument. And again, we want to do the same thing for the go away for the joint broad spawner. Now, you can also set these up to do tricky things like wait until the spawn entity node has finished running and then and then run these so that everything's definitely up and running. I find that there tends to be enough of a buffer in there that it should all just work, but you can add delays in there if you want. But let's add diff Drive spawner and Joint broad spawner. So, now we should be able to go back to our gazebo and run it again. And this time we should see that in the printout it says yep I've I've started those controllers as part of that launch script. It's all in the one terminal. We see our robots there. And just like before, we should be able to now drive it around.

so if you drive it around, now you should be able to see that everything basically works. If you take a close look, though, you'll notice a few things that are not quite right. In fact, there's a whole bunch of changes we're going to make before we get it running on the actual robot. But since this video is already pretty long and they're not directly related to ROS2 control, I've put them in an extra video that you'll find a link for in the description so you can head straight to that after this one. One quick little extra topic I didn't cover before is Transmissions. Now, Transmissions were a really key part of ROS control back in ROS 1, but then when ROS 2 control came out, they weren't really a part of it. So when I started using ROS 2 control, there was no Transmissions. I learned how to use it without it. Transmissions are working in ROS 2 control now, and I'm not totally on top of how that works, so I'm going to

save that as a topic for an extra video. I'll do an update down in the future where we'll look particularly at transmissions and how to use them. But as it is, you don't need to use them. So if you just came here to learn about ROS 2 control, I hope you found this to be a helpful overview, and please consider subscribing, especially so that you don't miss out on the next video where we run ROS 2 control on a real robot. But if you are following through the whole mobile robot build series, then make sure you watch that extra video linked in the description so that you're all prepared for when the next main video comes out. If you've got any more questions about the things I've covered in this video, there's another link in the description to the discussion thread over at the Articulated Robotics Community where you can join in the conversation. Lastly, I just want to give a massive shout out to everyone who is supporting me on Patreon. This is the first video to go up since

the patreon's been live, and I've been absolutely blown away by people's generosity and their desire to see more freely available content like this. If you would like to consider supporting me, there's a link for that in the description. Alright, I'll see you over in the extra video. [Music]

Solving the problem EVERY robot has (with ros2_control)

Instructional and entertaining videos on the subject of robotics. Including theory, practice, and using ROS.

Solving the problem EVERY robot has (with ros2_control)

Solving the problem EVERY robot has (with ros2_control)

Scripts