ROS on the RSLK
Masters Project: Capstone (Fall 22)
This project acted as my Computer Engineering Masters Capstone. The objective was to control a Texas Instruments Robotics Learning Kit (TI RSLK) using Robot Operating System (ROS).
Why the RSLK
Armed with motor input control and the distance that the wheel has turned we can now control how far the RSLK drives. Want to drive one meter… set the direction forward (rotation direction depends on right/left wheel), set the drive speed (0-255) and accumulate encoder ticks until 1 meter has been reached. DONE! Unfortunately for us the ROS standard uses VELOCITY for navigation therefore a few more steps are required. If we can determine distance then all we need is the elapsed time and we can calculate velocity. Therefore in the backround as the code on the RSLK is constantly looping through recieving and broadcasting messages there is a timer counting how long the loop takes to run. If we divide how far the wheel has turned in that single iteration of the main loop, and divide that by how long it took to drive that far then we have the current rotational velocity of the wheel.
The RSLK has been adopted by UNC Charlotte as its default robotics platform for years due to its price and ease of use therefore the school has a collection of RSLKs for students to use for entry level classes, and students can afford their own for upper level classes.
Why ROS
ROS is an open-source framework that helps researchers and developers build and reuse code between robotics applications. ROS is also a global open-source community of engineers, developers and hobbyists who contribute to making robots better, more accessible and available to everyone.
Benefits of ROS on RSLK
Allow ROS to be taught in robotics courses
The largest ROS learning platfrom is the TurtleBot. The TurtleBot is a great entry platfrom for learning ROS however although it is low-cost compared to the market the $600+ price tag is too steep for students to purchase. The RSLK retails for ~$125.
Allow RSLK to be used in additional courses, such as the previously available Simultaneous Localization and Mapping course (SLAM)
Brief Overview of ROS
So if the computer is telling the robot where to go what is the robot doing? A lot actually! The RSLK is constantly publishing multiple messages to the computer such as its location relative to its start point, bumper status, motor status, and more(of course this varies depending on robot and required info/capabilities).
Controlling the RSLK
The velocity message that the host recieves is shown in the following format:
Left Wheel Right Wheel
[Direction, PWM speed, Velocity, Direction, PWM speed, Velocity]
To the right is a video showing the messages received in real time on the bottom right consol. For this video the host is telling the RSLK to drive forward at 0.10m/s, both motors are driving forward with a direction value of 1.0, and the drive speed for each motor is about 25 out of 255.
Of course there are algorithms implemented to enhance the motor control responsiveness. For this application I implemented a Proportional Integral control loop which proved very responsive.
The RSLK is expecting a linear-x velocity and an angular z velocity. Simply put if linear-x if a positive value the robot will drive forward. To turn the RSLK we need to introduce an angular-z velocity. If the RSLK is driving forward and an angular velocity is introduced the RSLKs path will now arc and if unchanged ideally the RSLK will now drive in circles. If the linear-x value is zero and angular-z value is non-zero the RSLK will spin in place.
With all of that being said the linear-x, and angular-z inputs from the host need to run through a formula to determine the velocity required by each wheel. Driving straight is simple, however complex paths require precise velocities from each wheel.
Odometry
Odometry is basically keeping track of where the RSLK is relative to its starting position. If we are on a cartesian plane facing up and drive forward 1 meter our coordinates are now (0,1). Turn right and drive forward another meter and our position is now (1,1), easy enough.
Odometry for ROS and the RSLK will show a third theta value showing the RSLKs rotation angle. In addition to the rotation angle the RSLKs position is calculated many times per second via each wheels linear velocity. The image to the right shows the translation of the inverse kinematic formula of a differential drive on the left to the working code on the right.
After the RSLK has calculated it new location it must broadcast its transform information to the host. Along with the x, y, and theta values a time stamp is required, as well as an id for the origin and an id for the thing being tracked. Remember… multiple robots/things locations can be tracked by the host at the same time.
Bumpers
Robot Description File
Simply put the bumpers are being monitored as well. There are six bumpers so similar to the motors we have an array shown in the video to the right to let us know if the bumpers have been hit.
For simulation purposes it is good to have an accurate representation of your robot so a Robot Description File (RDF) was developed for the RSLK. In this case the RDF sim is simply a visual stand in however additional functionality such as the wheels angular position can be modeled in simulation which would require an accurate RDF(not required here).
Progress Demo Video demonstrating ROS/RSLK functionality
A bit of ROS knowledge is required to explain the project so very briefly ROS is a framework intended to aid in robotics information/code sharing and generalization. To put it another way, the code used for ROS is written in a way that allows it to be used on multiple types of robots two wheeled, four wheeled, armed etc… in order to streamline prototyping. This is called Hardware Abstraction so by using ROS the user can focus on the software/algorithms rather than focusing on the software to hardware connection.
Without using much of the ROS nomenclature we can imagine that your computer is like a radio broadcast center and the robot/RSLK is your car radio. The car radio is set to the station of the broadcast center and always listening(it is a subscriber of the station) . If the broadcast center says drive forward (publishes commands) the car hears that and then acts accordingly. In addition the car can call into the radio station to inform the station of the cars location and the station can change its broadcast accordingly. This communication structure allows multiple cars to listen to the same broadcast and the same station to listen to multiple cars.
Computer is broadcasting a velocity command to the RSLK
To dive in a bit further the two motors each have two basic inputs, a value to control the voltage supplied to the motor and a value to control the motors spin direction (clockwise or counter clockwise). Unfortunately even if you give the maximum speed value to a motor the RSLKs actual speed will vary significantly depending on the current voltage of the power supply (batteries), the floor material type, if the robot bumps anything, or even simple variance in motor production. To solve this issue, magnetic encoders are used to determine the wheels position as it spins. With 360 encoder counts per wheel rotation the RSLK has 1 degree wheel precision or about a 2mm driving precision.
The code located on and organizing the velocity broadcast from the RSLK is shown on the right. This message was organized into an array of 6 elements: direction, PWM speed, and calculated linear velocity of each wheel. Previously I described rotational velocity of each wheel but if you take that rotational velocity and the circumference of the wheel you can determine the linear velocity which is more helpful in this case.
Custom Expansion Board
To the right is the HAT schematic. Again the HAT needed to serve the following requirements:
Serve as an easy connect for
3 HC-SR04 ultrasonic sensors
1 Servo
1 I2C(LIDAR)
1 Grove Connect
1 XBee
On the right is a great video displaying odometry combined with rViz visualization. In this example there are two things being tracked, the RSLKs location based off of encoder velocity accumulation(ENCODE) and the simulated(SIM) location. SIMs location assumes perfect adherence to velocity commands, while the ENCODEs location is where the RSLK is more likely to be (this location will never be exact). In the video to the right (there is audio if you want) I am starting from an origin named odom, and tracking the location of SIM and ENCODE.
Moving left to right the top terminals show the command velocity window, the odometry transform viewer, the left wheel velocity, and the right wheel velocity. Moving left to right the bottom windows show the RSLK and inputting commands, rViz visualizing the odometry information, and the rightmost window is required to establish a connection between the host and RSLK.
This visualization is a great example of Dead Reckoning. Dead reckoning simply put would be if we want to drive forward 1 meter we would tell the RSLK to drive forward at 1m/s for 1 second. This would work in theory however with no feedback this process is prone to error, and overtime the errors can accumulate substantially leading to a non-ideal final position. The video shows the error over time accumulating between the optimal expected rout of SIM labeled as chassis vs the more realistic measured ENCODE labeled as chassisEncoder.
DEMO TIME!
The observant reader may have noticed by this point that the RSLK has been on a desk in all demo videos up to this point. Unfortunately the RSLK does not come with stock wireless capabilities, however there is an expansion board that can be purchased from TI. The idea for a custom PCB header board (HAT) was discussed and included as part of this projects deliverables. This HAT was required to connect a bluetooth device called an XBee to the RSLK to allow wireless communication. In addition to the XBee the HAT was built to leave all RSLK header pins still usable as well as creating a mounting point for a servo motor and 3 ultrasonic sensors to simply the hardware hookup process for students in an intro robotics class.
Hardware mount for servo
Channel selectable UART
Selectable TTL lvl
The HAT worked without a problem and did indeed provide the RSLK wireless connectivity to the host which ROS so desperately needed.
After the HAT was deemed working for additional functionality I designed a pen holder to attach to the back of the RSLK. By dragging a pen behind the RSLK its path will be drawn as it moves creating clear immediate visual feedback of the RSLKs path and any drift or errors within. After designing the stationary pen holder I decided to make a motorized holder that way the pen can be lifted/lowererd to increase the drawing capability. A linear-z velocity command was used to raise/lower the pen. On the RSLKs code if the linear-z velocity was greater than zero the pen would lift, if not the pen would drop.
With most of the project explained lets put it all together and see it in action. A simple program is run on the host which will broadcast velocity messages instructing the RSLK to drive forward, draw a circle, drive forward, and stop (with a few more steps in between). This one demonstration displays the following:
Velocity commands operational
Odometry operational
RDF (in rVis) operational
Motorized pen operational
Full PowerPoint Presentation