Templating Forward: How (and WHY) We're Upgrading ROS's Kinematic Templates
Most ROS developers start with standard two-wheel diff drive templates. At Polymath, we've started creating and templatizing models for other kinematics.
Most ROS developers start with standard two-wheel diff drive templates. At Polymath, we've started creating and templatizing models for other kinematics.
At Polymath Robotics, we're building safety-critical navigation for large industrial vehicles.
That means we work with multiple kinematic models, each of which poses its own unique challenges. The ROS community has standardized around two-wheel diff templates. We're working to create and open-source templates for other kinematic models, so those types of vehicles can perform better in the field.
If you are part of the ROS community, you’re probably familiar with 2-Wheel Diff Drive.
But for the sake of this post, let’s recap:
Two-wheel diff drive is when a vehicle uses two wheels to steer itself. The wheels can each be rotated, and when both are rotated, the vehicle can spin in place (kind of like Pixar’s Wall-E, without the treads).
When you look at the open-source templates out there for diff drives, two-wheeled options are really the default.
Four-wheeled and track-based vehicles have traditional kinematics that already exist, but the models haven’t been implemented in ROS (at least, not in a template-able fashion).
Often we work around this gap, by making one-off changes based on the vehicle we’re working with. But realistically, that’s not a scalable approach.
We often see people in the robotics community look at the standard two-wheel diff drive templates and think, “You know what? It’s good enough for these smaller indoor robots.”
Realistically? It often is!
With low-friction robots operating on relatively non-challenging surfaces, there’s no harm in using the standard template as your basis.
As we start to look at larger outdoor vehicles with different kinematics (think four-wheel diff drives and beyond), the smaller errors from things in the ROS ecosystem or collected through sensors add up quickly.
GPS and IMU help resolve these errors, but the more problems you stack on top of that robot position estimation, the more you drift away from accuracy.
Using kinematics made specifically for the vehicle type matters. It helps give you a more accurate estimate of where things are, and ultimately you’ll have a more consistent and precise approximation of where your robot is in real space.
Working with vehicles like bulldozers and four-wheel track vehicles quickly made it obvious that our team couldn’t keep using the default two-wheel diff template forever.
Certainly, you can try to have your vehicle run and rely heavily on sensors, rather than kinematics. You could say “OK, take the estimation and your kinematic model with a grain of salt. Rely on the GPS and IMU instead.” But if you struggle with your GPS and IMU at all, everything falls apart.
Realistically, your odometry (GPS and IMU) often blinks in and out. Who wants to use a spotty, possibly accurate signal of reality if you can improve things so dramatically with a better kinematic model?
Having accurate odometry and a more accurate kinematic model is like having two guides that can help each other when one’s in trouble.
The kinematic model helps bridge the issues with accuracy in sensors, while those sensors help keep things on track when the math isn’t reflecting real-time ground conditions.
Creating templates for vehicle types beyond two-wheel diff drives will require a handful of things to happen.
Developing the mathematics, open-sourcing the project, making sure the software engineering standards are strong, and making sure it’s easy from a C++ implementation perspective are all key milestones to creating these templates.
We know that it’s easy to hard-code vehicle configurations alone, but then you sign up to maintain multiple repositories - that isn’t the right solution. It isn’t production ready, and it isn’t the future.
Vehicle automation needs open-source solutions like this to evolve and become sustainable.
We’re hoping to take a step in this direction, making ROS more robust for ourselves and for the robotics community.
Get updates & robotics insights from Polymath when you sign up for emails.