today, we're going to be looking at taking a JetBot, including the motor control code that we looked at last video. Link at the top of the video, and we'll be wrapping it in a ROS 2 control system so that we can use it with the ROS 2 control Library. Hi, and welcome to Mike Likes Robots, where we share our knowledge to accelerate robotics. We're going to start by looking at ROS 2 control Concepts, including the controller manager and the different types of resources that it can use. Then we'll look at how to implement that on the JetBot, and then we'll show the JetBot actually working with the new system in place. Let's take a look at those ROS 2 control Concepts. The first thing to make clear when we're talking about ROS control is that there's two options. The first is ROS control, that's the control system for ROS 1. There's also ROS 2 control. Now, although they have very similar Concepts in a lot of way, as we'll see in the architecture diagrams, they are different systems and they don't work together.

this video is about ROS 2 control. In ROS control, we can see a similar separation: controller manager, controller, and hardware interfaces. In the same way, ROS 2 control has a controller manager and a controller concept, as well as the system interfaces: sensor system and actuator. The point of ROS 2 control is to provide a repeatable separation of the components of a control system. The controller manager, for example, can load different controllers during runtime. A controller is responsible for controlling a particular type of robot. For example, the JetBot and the TurtleBot are both differential drive robots. They both have a wheel on each side of the robot with casters to keep it level. You can imagine that if you can abstract away the ability to move the motors, you could write one module, one piece of software that's capable of driving both robots. You would just need to provide that controller the ability to move the motors in an abstract way. That's exactly what the ROS 2 controllers library provides us. Among other generic controllers, it provides us a differential drive controller, which

you can set up to access the motors on your robot and drive it around as a differential driver. That's what we're going to be doing in this video. We're going to be setting up the differential Drive controller from ROS 2 controllers to drive our robot around, and we're going to give it the motor and IAD seed device classes that we wrote last video. Get us started writing a custom ROS control system. The ROS 2 control framework helpfully provides us this set of demos. There's a documentation page, as I'm showing now, which shows exactly what you can find in the repository, and also the GitHub repository itself. As we're writing a custom system for moving a Jetbot, we can use the example 2 example that's available in this repository. In fact, we can copy it pretty much as is and fill out a couple of the methods, although we'll be going further. We're going to strip out everything that's not important for actually running the robot, so we'll remove everything to do with simulation and materials just so that we

can look through the code and understand exactly what's going on. So, let's take a look at the code now. Here we are in the GitHub repository containing the code. I'll be using for this video. This code will completely build a ROS 2 control system that works with the Jetbot motors so that we can move it around using ROS 2 control, including with the keyboard operator that we first used in the original Jetbot setup video. So, let's check this out on the Jetbot, and then we'll have a dig through the code within VS Code and see what's going on. Here I am SSH into my Jetbot, and the first step will be to clone the code. What I'm going to do is create a workspace folder to clone the code into. Inside that folder, I'll do a git clone with a GitHub repository and also specify the tag of Jetbot Motors part two. Now I'm going to copy the dev container from that checked out repository that will help me run this inside Docker, which will give me access to ROS 2, which I otherwise wouldn't be.

able to access there's more information available in the jetbot Deep dive video that I'll link at the top and in the description. Then I can open code within this workspace, and it will give me the option to open that container. I can execute the rebuild and reopening container command, and once that container build is complete, I have access to all of the source files within the jetbot Ros control folder. The next step is to take a look at the updated cmake list file. In the last video, this cmake file was used to build a rosu executable node which span the motors for half a second every second. This time though, we're doing something different. We're building a library that can be used as a plugin for a controller. So instead of building an executable now, we're using a Library. We're specifying the jetbot system class that's new and is the ros2 control system that can be loaded by the controller, and we're specifying the i2c device and motor files that it needs to use to communicate with those Motors.

over. I C further down, we can see this other new line: plug-in lib export plug-in description file. This is because ROS2 control uses plugins. This plugin library and to understand what a plugin is, it needs a plugin description file. In our case, it's called jetbot control. XML. If we look at this jetbot control XML file, we can see that it specifies a name, a type for the plugin, and it also has a base class of system interface. And that's because we're building a system rather than an actuator or a sensor, so that we can move both motors with one right command or read both motors with one read command. It makes everything a bit simpler rather than having separate actuators. Now that we've seen the new XML file and the changes to the CMake lists, let's take a look at the source code and figure out what's going on. First, we have a new header file, the jetbot system HPP file. This states that our new jetbot system Hardware class is of type system interfaces, and it also

gives all of the methods that we need at the bottom. In private, we also have the private fields that we need during runtime. So we need to know what motor pins to use to communicate with the motors. We need to keep an i2c device, and we need to keep a list of Motors that we're communicating with. There's also Hardware commands and velocities. These we make available to the controller so it can directly write the commands it wants to send to the motors and directly read the measured velocities from the motors. Our code is about writing out anything that we find in the hardware commands vector and reading the motor velocities into this Hardware velocities Vector. That's essentially what we have to fill out. From the example, we can also take a look at these method names on init, on activate, and on deactivate are all life cycle methods. These are from a Ros 2 system of life cycles that specifies methods for initializing, activating, and being ready, and then the opposite way around deactivating and going into an uninitialized state. By specifying that we have an on

init method and an onactivate method. We have two separate places for initializing our code. We also have on deactivate for getting rid of that initialization afterwards. Otherwise, in this file, we need to export our State interfaces and our Command interfaces, and I'll talk more about what those are when we look at the robot description. Finally, we've got our read and write methods, where the read method allows us to read velocities from the motors, and the WR method allows us to write the commanded values to the motors so that they move at the speed required by the controller. Now we'll look at the source file to see how those are implemented. This is where we're allowed to actually initialize the plugin Library. First, we set our velocity and commands up, then we set up our pins. We read out the pins from configuration that we need to communicate with the motors, and then we check that we've got the right joints available. And again, I'll talk more about joints and their command and state interfaces when we talk about the robot description.

that's done. We're able to initialize the I2C and motors, which is very similar to how we did it in the Constructor in the previous video. And when we get to unactivate, we're allowed to enable our Motors and set their velocity to zero. On deactivate, we set their velocity to zero again so that any active motion is stopped. The read and write methods are much more simple in comparison. This read method is doing nothing. It just simply returns okay, meaning that there was no error in reading. And I'll explain why there's no reading here later in the video. The write method takes all of the hardware commands and writes them in turn to the motors. So what that is, is the controller sends move at these speeds on these motors, and this is us actually doing that through the I2C device through our motors that are initialized. Finally, we just need to export the class as a plug-in Library, which makes it able to load from the controller. So that's our source code. Once we build this, it builds a library that can be loaded by the Ros.

2 control system, but we still need to set up the ROS 2 control system. How do we specify that it's a differential drive controller, and how do we specify what the robot parameters are? That's what's coming next. It's the description part of the robot. Now, this comes in two parts. We have the ROS 2 control zacro file. What this is, is a file that defines how ROS 2 control should be implemented for this robot. We can then import that macro definition into our overall robot description. Now, normally this overall robot description file would have a lot more content because it would have simulation parameters and materials that are being used. That's what's in the example, but these have been stripped out so that we don't need to worry about the simulation parameters. Inside the ROS 2 control macro that we've defined, we've got a ROS 2 control system. It will load the Jetbot system hardware as a plugin that we've just built as a library. It will also set the pins that we need to contact the motors. However, we have the option to use

mock Hardware. And if we do so, it will load a generic system instead. Because we're on the JetBot, we don't need to use this. But if you're just running this on a desktop, you could specify use mock hardware and see the system run without the full JetBot system hardware. Then, once we've specified the plugin to load, we need to give it joints. Now, a joint in ROS 2 control is a part that can move. For each joint that can move, for each joint, we need to specify what state interfaces are available and what command interfaces are available. We can see here that the name is specified because we require the ability to write velocities to our motors. There are other options here. We could specify position, we could specify effort, or we could even specify a custom type if we wanted. But as we saw in the previous video, we specify a value from -1 to 1 that we write to the motors in order to move them from their maximum reverse speed to their maximum forward speed. Therefore, we want to write from -1 to 1 to our motors. We also have a

state interface of velocity where we report the measured values from the motors. However, we don't actually have anything that's measuring values from the motors. There's no encoders and no other sensors here. So, really, we're not actually reading the velocity, which is why that read method earlier did nothing. Instead, we tell the controller to run in open loop mode. Now you can imagine open loop as being blindly trying to do something, and closed loop as having feedback that allows you to more accurately do it. If you don't have a feedback mechanism, you will find that the accuracy is much decreased. You can often run faster and much more accurately if you have a feedback mechanism providing that closed loop control, but we don't have that on the JetBot. So, we have to run in open loop. For each joint of left and right wheel, we specify a velocity command and a velocity state where the velocity state is ignored. That's our ROS 2 control system defined for the JetBot system, but we still have yet to define the differential Drive.

controller. That's where the next folder comes in. Bring up in our config section. In bring up, we can see this JetBot controller's YAML file. Now inside here, we specify that there is a controller manager that requires a JetBot base controller. And it's here that we specify it's a diff Drive controller. Then, because our diff Drive controller is named JetBot base controller, we can provide parameters to it. We can tell it that the left wheel names a left wheel joint and the right wheel names a right wheel joint. And we can give other parameters. The wheel separation is measured in meters and is the closest distance between two wheels. The wheel radius is also measured in meters from the center of the wheel to the very outer edge. These I've measured from my robot. Here we're specifying that it's open loop, which I've already discussed that there's no position feedback available. And down here is where we can set velocity limits. This is where we can start to configure the controller more to do what we need. We can specify that.

there's a Max velocity to send to the motors, and a Max velocity that they should turn at. Now these numbers I found through experimentation. Normally, the controller will send units of 1 per second, which you can interpret as radians per second, but for our Motors, that doesn't actually correspond to a real-life measurement because we're going minus one for maximum reverse to plus one maximum forward. That doesn't always map to the same velocity, so instead we're just going to guess numbers, and there's no feedback mechanism to correct them. So these are just numbers that I've obtained that give a reasonable rate of movement. The controller manager here corresponds to the controller manager in this architecture diagram from the ROS 2 control documentation. We can also see that controller A would be the Jetbot base controller, and we don't have any other controllers that we need to specify because we never switch to another controller. We can also see this system, which is our Jetbot system hardware and is able to interact with our system. We've talked about State.

interfaces and command interfaces. So now we've seen how everything in our system maps to this architecture diagram, except for the resource manager, which is inherently built. And because we never have to share resources, we don't need to worry about that constraint. The final piece of the puzzle is the launch file. This is the script that actually starts up all of our nodes. We can see that there's an argument for use mock Hardware, which allows us to launch without using the Jetbot system hardware. And then we can see that we use the zacro executable. That's because our ROS 2 control system that defines a macro is not actually XML; it's zacro, which can compile to XML using zacro. So what we're doing here is using zacro to expand our full robot description file, our full URDF, into something that will be recognized by the controller. We can then specify our Jetbot controllers, which gives us all the configuration we need to launch the controller manager. Now we spawn a node for the controller manager and give it all of the description and controller configuration.

that we've just read out of those files. We also request that the controller manager spawns the JetBot base controller as the first controller. And those are our only two nodes. So we've started at the bottom layer of writing I squared sea Motors, and now we've reached the top layer of using ROS 2 control to spawn a controller manager that controls our robot for us. We did that by building a plug-in library that we fed to the differential Drive controller that we spawned using the controller manager from ROS 2 control. That's how our entire system fits together. Now let's build it and launch it and see it in action. We'll build it by first sourcing our setup. bash. Then we'll do a CMake build and wait for that build to complete. With our build complete, we can source our local workspace, and now we're ready to launch. Once we execute this, all of those nodes from the launch. piy file will run in order. Now if we take a look at the log, we can see that it loaded and

initialized the hardware for the JetBot, and then activated it with a successful activation. Now it's ready to run. Don't worry, that the process is finished. Cleaning that's a node that spawns our controller for us. So, that's just saying it's done spawning the controller. Now we could move this around if we send a command to command Vel. And to test it, we're going to use the keyboard. But in order to make that to work properly, there's a couple of issues. The first issue is that if we list the topics available, command Vel isn't here, which is the default topic that's written to by the keyboard operator. So, we need to remap it to this topic instead. The second issue is that this topic takes twist stamps where where normally it takes just twist. That means we need to reconfigure the keyboard node to send twist stamped messages instead. Unfortunately, although it has a field to do that, I found that the current version of the software doesn't work. The one that I installed out of apt what I had to

do was clone the source and run it from there. So that's what we're going to do. We can get clone, we can do another build again Source our workspace. Then we're able to run teleop twist keyboard, except we'll remap the topic and we'll specify to use the time stamps. We can do that with this command that specifies the time stamps with stamped and the topic remapping with - R. Now if we ask the robot to move forward, we can see it's actually moving. Let's ask it to move back. So we're using the controller to control the movement of the robot. It will adjust based on the maximum velocities and accelerations that we've configured it with, and it will adjust based on the parameters that we've given it with the wheel radius and the separation. That means that we could run the same system on a turtle bar. Only we'd need to change how it talks to the wheels and just change those parameters in order for it to work correctly. Now let's see it work in the real world here.

we're running with the default speeds and able to spin in a circle with full control. We can also edit the JetBot controller's configuration to decrease the max acceleration, although the maximum velocity remains the same, and we can increase the max acceleration so it jerks to a hole. So there we've seen some of the ROS 2 control concepts: the controller manager, the controllers themselves, and the resources that we need to be able to connect to our robots and run them. In this case, it was simplest to use a system to drive our JetBot around, and we showed that working. Now it's properly integrated into ROS 2, and we can start to do more advanced things like using ROS to plan splines for us or using simulation and running this in Gazebo. We took all of the simulation stuff out because we didn't understand it and we didn't need it, but next time we can start to put that stuff back in and see how to control our robot in simulation. Thanks for watching, and I'll see you in the next one.

Building a ros2_control System | ROS2 Control with the JetBot Part 2

This channel is all about showing how to use the cloud's power in robotics through technical explanations and hands-on demos.

If you're intrigued, consider subscribing!

Do note - I work for AWS (@amazonwebservices), and my opinions are my own.



Building a ros2_control System | ROS2 Control with the JetBot Part 2

Building a ros2_control System | ROS2 Control with the JetBot Part 2

Scripts