In this video, we're going to learn how to use ROS2 control with an actual robot. Now, this is going to flow on directly from the last video where we looked at the concepts of ROS2 control and how to use it with Gazebo. So, if you haven't watched that one yet, pause this one, go and watch it first, and then come back. The main goal of this video is to get our robot driving around. But before we get into that, I just want to take a moment to recap and clarify a few of the concepts and ideas around how we're going to use ROS2 control to control this robot. So, at one end, we've got the physical robot. It's got two drive wheels. Each of which are velocity controlled. At the other end, we've got a body velocity request. That's the velocity that we want the robot to be moving through space. This could come from an operator or from something like a navigation stack. This particular robot's motion is quite constrained. In fact, the only thing it can do is to move.

forwards and backwards in X and to rotate around Z. So although our input is going to be a ROS topic of type twist or twist stamped as we'll see in the next video, that is a six-dimensional velocity, and we're only going to be using two dimensions: linear X and angular Z. We call this the command velocity, and the tool that we're going to use to link up the command velocity to the actual Motors is ROS 2 control. And this little ecosystem consists of three main parts. In the middle, we've got the controller manager. Then on the left-hand side, we've got the differential Drive controller. And on the right-hand side, we've got the motor Hardware component or Hardware interface. The controller manager is a node that's provided for us by the ROS 2 control libraries. The diff Drive controller is also provided for us as a plugin in ROS 2 controllers, although we could write our own one if we wanted to. And the hardware interface is a plugin that we need to provide ourselves. The diff Drive controller will convert

the command velocity into abstract wheel velocities, and then the hardware interface is going to turn abstract wheel velocities into motor hardware commands. The controller manager then just sits in the middle and links the two up together. In addition to this, we've got another controller called a joint state broadcaster. All this one does is read the motor encoder positions provided by the hardware interface and publishes them to the Joint States topic for robot state publisher to use to generate its transforms. For this kind of robot, it's not strictly necessary, but it makes the whole system a bit more complete. In the last video, we set up our controllers, but in that case, we were using a gazebo controlled controller manager and a gazebo hardware interface, whereas this time we want to be running our own controller manager using our old hardware interface, and most importantly, running it on our own robot. The first thing we're going to need to get set up is our hardware interface. Now, if you're using the same Arduino motor control code that I am, then you'll be able to use the hardware interface that

I've written. Otherwise, you're going to have to write your own or search online for one. I'll have a bit of a look and see if I can include in the description some links to some common ones, particularly say for Dynamix or Motors. I know that they're popular now. Writing your own Hardware interface is outside the scope of this tutorial, but if you are interested in that, let me know because they changed the API after foxy and so I need to rewrite my one anyway to work with foxy, and it might be a good chance to cover that. So if you're interested, let us know in the comments. For this tutorial though, we'll be using the one I wrote, and it's called diff Drive Arduino, and all it does is it exposes those two command interfaces, that's the velocity of the left wheel and the right wheel, and it controls them using those same M and E serial commands that I showed back in the motor control demo video. It also exposes the four state interfaces, so that's the position and the velocity of each wheel and then.

the control is all going to happen in the same diff drive controller that we showed in the last video. That's all handled by ROS control. Now, to actually install my hardware interface, it'd be nice to be able to just type sudo apt install diff drive Arduino. Unfortunately, we can't do that right now, and that's because back when I wrote it ages ago, I based it on this particular serial library that was never officially updated and released for ROS 2. There is a source code version of it, so we'll be able to clone that into our workspace and compile it from source. Since then, there has been a different serial driver for ROS 2 released, so I might rewrite it to be based on that one, but I really like the old one. So, William or Scott, if you happen to be listening to this, then please consider doing a ROS 2 package release. If that ever happens, or if I do end up rewriting it to be based on that other package, then I'll package mine all up so that it can be installed.

throughout, and that'll simplify this process for now. Though we're just going to clone them both into our workspace to keep things simple. I've created my own Fork of Scots Fork of Williams serial Library. So, to do that, we're going to go onto the I have already SSH into the pi. I'm going to get into my workspace and the source directory. And then we can go get clone. All right, so they're cloned now. So we should be able to see we've got the diff driver Arduino package and the serial package in our workspace now. If you haven't already cloned your main package for the project, make sure you do that. Otherwise, if you have, we probably need to pull it since the changes from the last tutorial. So I'll just hop into that one into our Tiki bot one. And we'll just get pull. All right, and now we can hop back into the root of our workspace and build it with colcon. This might take a little while because it's going to build the serial library and stuff on the pi.

the other thing I forgot to do was to actually install ross2 control. In the last video, we installed it on the dev machine, but we haven't installed it on the pi yet. So we'll just quickly pseudo apt install Ross foxy ros2 control and the controllers. And then we'll try and build again. So colcon. All right. Now that we've got through the build, we can start configuring things. Now you can edit the files on your robot however you want. I only use the vs code SSH remote development tool, but you could also use a command line editor through SSH. Or you could edit the files on your Dev machine and then sync them across when you're done however you want to do it. So here's the SSH connection that I used back in an earlier video. I've just gotta enter the password. So I'll close this up here. Lidar.launch Pi. I've got there. In fact, I can actually get rid of these two files because we don't need them anymore. They were from earlier testing and we've actually moved

them inside our package. Now, let's take a look at our URDF. So, if we have a look at this file here, ros2_control_xacro, this is the one we edited last time when we set up ROS2 control for Gazebo. Now, what we're going to do this time, we're going to copy and paste this block, this ROS2 control block, and then I'm going to comment out the Gazebo one. So, we're still going to keep it, and at the end of the video, we're going to show you how to re-enable that so that we can swap between the real one and Gazebo. But, so we'll leave that there, and this new one is going to become the one for our new system. So, we better give it a new name. Let's call it real_robot_agv_type_system. And now, we need the name of the plugin. So, my plugin is called diff_drive_arduino. The underscore scores are a bit funny, but diff_drive_arduino/diff_drive_arduino.

and everything else is obviously just going to stay the same. We've got those two joints, but the next thing we need is to set a bunch of parameters for our plugin. So under here, we can set parameters that are going to go into that Hardware interface. So for us, that's going to be things like the board rate and that sort of thing. So I'm going to go copy them from somewhere else. Now we're going to need to fill these things in. So left and right we'll name well we know them. They're just the names of our joints that we've already got here. Now the rest of these parameters are the same ones that we would have used back when I did the serial motor demo video. So I'm just going to check my history to get them. And so we can see our serial Port. I've got there as slash Dev TTY USB 0. That's a bit bad. We actually need to um set it up to different differentiate between the lidar and the Arduino, but we'll leave that for now. The board

rate is 57,600. And the encode accounts for evolution is 34.50. What do we got sorry I'm going in a funny order, uh, the timeout so this is just the serial timeout so I'm just going to set that to for 10 milliseconds. I'll set that to a one second, and then finally our Loop rate was 30. So that should be all the parameters that we need for our Hardware interface. The next thing we're going to need is a launch file so we'll go into our launch directory. I'm going to take our launch Sim Dot launch.pi and I'm going to copy and paste that. And we're going to call this one let's call it launch robot dot launch dot Pi. Now what's going to be different in here well to start off with we're going to get rid of these sections in the Middle where we were spawning gazebo and instead what we will need to do is spawn the controller manager. So I'm going to for now just copy this diff.

Drive spawner node, except we're going to call this one. I'm going to call this one controller manager. Now the package is the same as controller manager, but the executable for this one is called the Ross to control node. Now this one doesn't have arguments per se like the spawner did. Instead, it's got parameters. So we're just going to leave that as an empty array for now, and we're going to fill that in. Now you might remember from the last video that there's two things that need to go into our controller manager. It needs the URDF so that it can find the information about the hardware interfaces to load, and it needs a params file that tells it which controllers it needs to load. So we'll start with the URDF. Now this one's going to be a bit funny. Normally programs just get that from the robot description topic that's published by Robot State Publisher. Unfortunately, as far as I'm aware, Controller Manager can't do that. The Gazebo ROS control one does do that, but this one we're going to have to get

it ourselves. And so the way I'm going to do that is I'm going to use a command substitution. We talked a bit about this in the extra video at the end of the last one. So what this will do is it's going to just execute this command, which asks the robot State publisher node to return its robot description parameter as a string. And we've got to make sure we do the python include for this. So it's from launch dot substitutions import command. So we've got this command. Now what we need to do is we need to tell it to send that as the robot description parameter. So we'll type robot description and then whatever is in that robot description variable, which in this case is a command substitution, is going to get evaluated and saved as that parameter. So it's a bit weird, but it will work. So that's that one. The next one is our params file. So to do that, we need to get the path to the file. And accidentally left this one here, but that's quite convenient. So let's take that and move

it down here, but this time we're going to call it controller params file, and the path to this one is our package name and then config directory. So that's here, but this time it was mycontrollers.yaml. So my_controllers, and then what we can do is we can just pass that straight into the parameters here. So controller params file, so it's going to launch a ros2 control node. It's going to set its robot description parameter to whatever the output of that is, and then it's going to take whatever other parameters we've specified in this yaml file and shove them in there as well. Hopefully that makes sense. Now, in this params file, you might remember that we set use sim time to true. I'm actually going to comment that out because we don't want to be using Sim time on the real robot. Now again, that's going to break gazebo, but we're going to fix all that up at the end, so we'll just leave that for now. The other spot we've got to change it that I forgot to say here is where we

include the robot State publisher launch file. We want to set use sim time to false. There I forgot to do that, and it caused me some trouble later on, but I deleted that part out of the video. You want to make sure you change it here. The other problem we're going to run into is this is going to want to start up straight away before the robot State publisher has finished starting up, and so this command is going to fail, and it's all going to stop working. Now there are proper ways to time delay days and that sort of thing in Ross launch files. I've had a bit of a fiddle with that, and I can't really get it to work well in this context. So instead we're just going to set it on a timer. So the timer we better import it up here. It's an action like this. So we'll import the timer action, and then here where we've got our controller manager, I'm going to make a new one called delayed controller manager, and that is going to be a timer action.

the period is going to equals this is in seconds. I might set mine to be three seconds, and the actions that it's going to execute is going to be the controller manager. So the delay controller manager is a timer action that after three seconds will run whatever this was. The next problem we'll then run into is potentially the spawners taking too long to go because this one is delayed. Now in my experience it usually is fine, but let's just do this nicely. We're going to tell it to not start this controller spawners until after it has started the controller manager. Now I've actually kind of got the code for that already written down here. I mentioned that in the other video. So we're gonna take these two lines here and put them up the top so we've got the ability to register event handlers and also the on process exit event handler. Except this time we want this to be on process start. So as soon as the controller manager starts after being delayed we want to do the other one.

so I'm going to grab this code here. The delayed diff Drive spawner. So register event handler. This will be on process start. The target action is the controller manager because we want it to start when the controller manager eventually starts. And then we want it when that exits. What do we want to do? We want to run the diff Drive spawner. We'll then do the same for the delayed joint broad spawner. This should be on start, not on exit. So sorry I rushed through that a bit. You don't really need to do it. It just makes things a bit neater. So we'll delay the start of the controller manager. And then when it eventually starts, we'll launch the two spawners. So then finally we've got to put all that down here. So these are the ones we got rid of. We'll press this with delayed controller manager. And then these two are our delayed spawners. Okay, that should be everything we need. So let's hop back here into the SSH terminal and we'll rebuild.

because we've added some new files hopefully we haven't made any mistakes. Now I strongly recommend you prop the robot up before you do this because if the wheels start spinning and do something strange you don't want it to run away on you. So I'll just prop it up like that. Now what we want to do is run that launch file. So we'll source our installation and then Ross to launch Tiki bot one. Launch robot dot launch dot pi. Oh, turns out we are missing a comma there. Let's try that again. And that's funny. Apparently we hadn't installed exact row on the pi. So I'll just quickly install that. Okay, let's try running that one again. So we'll see it starts up robot state publisher. Now it's waiting a few seconds before starting the controller manager. There's our controller manager. And now it's started the controller spawners. And that's all up and running now. So what we can do now is back on on this machine. I'm going to launch Arvis and I'm going

to launch it with that configuration file that I set up in the last video. So that was in Dev workspace slash. And what we're looking for here is that with our fixed frame set to Odom, we should see that our transforms are happy and our robot model is happy. That means that all our controllers are up and running, and they're reporting everything that they need to report. And that means it's time to start driving it around. So what I'll do is I'll open up another tab, and I'm going to run the teleop twist keyboard. So this is, uh, there we go, teleop twist keyboard. Exactly the same as we were last time. So we're remapping the command velocity to command velocity unstamped. And so what I want to see now is that when I drive this around, I want to see the wheels turning here, and I want to see it moving in RViz the way that I should because that should be moving based on the feedback from the encoders. So let's try going forward and backwards.

left, right, and so I'm watching to see that the motors are turning in the way that I'm expecting them to. And now I'm going to try taking it off the stand and putting it on the desk. So I'm just going to go move the camera. All right, let's try some movements. So let's try left, right, forward. And now what I want to look at is whether the encoders are kind of doing what they're meant to. So I'm going to point this forward while it's facing forward in our views. And I'm going to try and do a 360-degree revolution. And we'll see whether we end up pointing back where we started. I don't quite know how this is going to go, so let's give it a shot. Okay, not quite. So that tells us that either we've got some wheel slipping or maybe some adjustments that need to be made in our controller. I'll have to have a bit of a look at that, but in principle, it's basically working. So we are

able to drive it around using the keyboard. Now, we can change the speeds that teleop twist keyboard's using. So, if yours is moving too fast or too slow, you can adjust that. But in the next video, what we're going to do is we're going to get it going with the controller, and that'll give us much more control. We'll be able to do fine controlled speed with the joystick and that sort of thing. Now, this is also a chance to start testing our sensors. So, let's try the camera. That's the easy one. Something's up with my camera position there, but if I enable the image stream, you can see it's working. Now, I've actually damaged my camera. I'll deal with that in a future video, but you can see that as I move this around, we should see the camera feed moving. What about the lidar? Let's see if it's working a bit better. There we go. So, we've seen the lidar data from our robot, and then as I drive the robot around the table.

we should see, in theory, that the lidar data stays in the same position. Now, I think in practice we'll probably find that due to whatever issues are going on with our encoders, things don't stay exactly right. You can see they stay in the same spot but maybe not perfectly, so something to work on there. For now, this is just a quick follow-up on some of those issues I was talking about before that was giving me poor odometry and how you can go about fixing those yourself. So, first up, we're going to check that the encoders are set up correctly. I've stuck a piece of tape on the wheel pointing upwards. Now, what we want to do is in our Vis swap to the base link as our fixed frame so that the robot's going to stay in the same position. Now, we can see how this y-axis is pointing upwards at the moment. And then what I'm going to do, I'm just going to drive for a while, and what we're hoping is that when I

stop and I get the mark on the tire pointing upwards again. That it's still pointing upwards and others. So let's just finish that Circle. Obviously it's a bit of slop in the wheel and we can see that that is pointing perfectly upwards now. If that wasn't like it was for me what you need to do is here in our roster control. We want to change our encode accounts per Revolution. You might remember I took those from my command history from an earlier video but in that earlier video I actually measured it wrong and talked about that at the time and forgot. So I adjusted my encode accounts per Revolution and now that works perfectly. The next thing we want to check is that we got our wheel radius right. So if I take this out of the way and pop it down on the bench. I've measured out a track of exactly one meter long and what I want to do is I want to see that uh yeah when we drive one meter it ends up moving one meter. So I'm just re-running

the controller to reset the positions of everything. We'll change our fixed frame back to Odom. Give it a minute to start up. So I'm going to drive it forward for one meter. And we're hoping that it moves forward exactly one meter. So far it's actually turned to the right a bit. I think there might be some differences between my two wheels. I'm not sure exactly what's going on there. But you can see that that wheel has moved exactly one meter. If that one's wrong, then you want to be adjusting the radius of your wheel here. So I've adjusted mine to get that right. The last thing we want to do is check that our wheel separation is correct. So for this one, I'm going to point it forward, restart the controller again, and now I'm going to do a 360-degree spin and point it forward again. And we want to see that our robot in Obvious is pointing pretty much forward. And that's about as good as we're going to get. And if that's not quite right, you

can adjust the wheel separation so that's how you can tweak those things and improve your odometry estimate. Now the nature of odometry is that it's never going to be perfect. That's why we do things like slam, but it is helpful to get it working as well as we can. Just be careful again if you're driving it around on the bench. Unfortunately, as I was driving mine, I drove it off the edge of the bench, and all of the sensors on the top plates are smashed on the ground, and it also scratched up my chassis a little bit. You might be able to see there, so I'm going to have to fix those up for the next video. Now that everything's working, let's go ahead and unbreak gazebo so that we can use both simulations and the real robot. So the first thing I'm going to do is I'm just going to get back into my artiki bot One Directory, and I'm just going to push my changes back to get. So we've modified our controller, we got rid.

of you. Sim time we added our extra bit to the Ross to control exactro, and got rid of the Gazebo bit. And we added our new launch file. So I'm just going to all right. So now I can pull those changes back onto the development machine. So we'll get into our Dev workspace, oh, pull those changes, and I'll open a new VS Code window that's in our development workspace. Just close all these. So now we can see it's pulled in our new launch robot. So the first thing we're going to do is we're going to fix up this roster control exactro. So now we've got the real robot section, but the Gazebo one's commented out. What we want to do is what we did at the end of the last video, if you remember, where here in the main one we set an argument called use ROS2 control, and we use that to toggle between ROS2 control and Gazebo control. So I'm going to add a new argument here called Sim mode, and I'm going to default that

to false. Now, when we're going ahead and toggling things in Sim mode, to be honest, there's lots of things we could change. Like all this gazebo stuff, we only need that in Sim mode, but gazebo tags are already only evaluated in Sim mode. So the only thing we really need to deal with is this section where we've got a ros2 control tag, and we need a different ros2 control tag depending on if we're in simulation or not. So we're going to use this same exact ro if and exacto unless syntax. So I'm just going to copy that and put it here. So this top one is for the real robot. So this one's actually going to be exact ro unless. So unless we're in Sim mode, then use that one. And we'll just fix up our indenting. And then we can uncomment this one and say if we're in Sim mode, use this. Okay, so unless we're in Sim mode, then we want our real robot. But if we're in Sim mode, use this one. Now, if we wanted we

could loop that in that same if we could have actually switched on just the hardware and left these joint names the same. But I'm going to keep these two things kind of separated so that they can do their own thing. So the next thing we need to do is actually pass this Sim mode argument down. So you might remember in the last one in robot State publisher we did this little thing here where we said exactro we passed down the use ros2 control. So we're just going to keep chaining on that. So our next one's going to be um Sim mode. And then what do we want to set that to be equal to? Well, I'm going to kind of cheat here. We've already got the use sim time parameter in robot State publisher. And whenever Sim time is on is when we're going to want to be in Sim mode. So I'm just going to set that here. So use sim time. Potentially you'd be better off doing it the other way around and actually calling this one sim mode and

then whenever we're in Sim mode, we want to set your Sim time to true. But this will be fine, so whenever you use sim time's true, we're going to be passing down Sim mode into the xaco file. Now, the other thing that you changed, if you remember, was in our controllers. We got rid of your Sim time here. So now, when we start up the controller manager, it's going to be trying to use non-sim time. Now, all of this comes down to this one's a bit confusing, but it's going to come down to here where we use the Gazebo Rost 2 control plugin. Now, I would have thought that maybe the Gazebo roster control plugin could automatically set your Sim time to true, but maybe there's a reason that it doesn't do that. The other thing that would be nice is if we could control individual parameters of Gazebo roster control here. So, I might be able to do something to set use sim time true to hear and have all the other parameters come from the file.

unfortunately, it can't do that either. But what it can do is, you can specify multiple parameter files. So, we can create another parameter file here, and it'll take all the parameters in the first one, and all the parameters in the second one, and shove them together. Now, that functionality has only been in Gazebo ROS 2 control for a couple of weeks, and it hasn't actually been pushed up to apt yet. So, if you're watching this video, like as soon as it comes out, that functionality is probably not going to be there, and we'll do that in a minute and get that to work. But we'll just pretend that it's working at the moment. So, we're going to call this one Gazebo ROS 2 control use sim. And then I'm going to take our my controllers.yaml here. I'm going to copy and paste it. I'm going to rename it that same name. So, Gazebo ROS 2 control use sim. And then I'm going to get rid of all of the other parameters that were in this

the only thing we've got in here is enabling you Sim time so back in our ros2 controller zachrophile. Whenever we're launching it in gazebo, it's going to load up the common controllers file, and it's also going to load up this roster control use Sim file. So now we'll give that a test. I'd recommend just trying it, and if it works, it works, and if it doesn't work, then do the extra step. But I know I'm going to need to do this extra step, so I'm going to get back into the workspace, back into the source directory. I'm going to get clone. Now I'm going to specify the branch as Foxy, and then the URL is. And then we'll rebuild with colcon build. All right, now that that's built, we can launch our simulation just like we did in the last video. All right, so that's all started. We can see here's the important thing, setting use sim time to true. So Sim time is getting set to true even though it was

not in this file, because it was in this file, and then looks like I closed my teleop, but should be able to drive it around just like we could before. Sweet, so now we've got something that should work with or without gazebo. Now we can drive our robot around, which is a huge step forward, and hopefully it's starting to feel like it's a real robot. Like I said before, in the next video, we're going to be looking at some Advanced Tilly operation, so we're going to be looking at how to control your robot with a game controller, and I'm also going to briefly look at how to control it with your phone with camera feedback coming to the screen. So make sure you catch that. Thanks so much to all the patrons who support this Channel and make it possible. If you found this video helpful or interesting, please consider liking and subscribing, or even supporting me on patreon. If you've got any questions or comments, there's a link in the description to a discussion thread over at the articulated robotics Community where you can join in.

conversation. Alright, I'll see you next time. [Music] Thank you.

Using ros2_control to drive our robot (off the edge of the bench...)

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