Welcome to the fourth blog in our AMR navigation spotlight series – interfacing with robotic systems, where we’ll be focusing on the technical considerations of getting your localisation data into robotic control systems. Click here to read the previous blog in the series, which discusses sensor timing and clock synchronisation.
So far, in our spotlight series on robotics, we’ve covered lots of technical detail about how to gather data for both localisation and perception on your autonomous mobile robot. The last step in that process – and the topic of this blog – is getting the data from your various sensors into your AMR’s control systems.
The challenges of interfacing with robotic systems
When you’re trying to use sensor data for localisation – and for perception, actually – you can’t just send the data to your robotic control stack and expect things to work. Once you’ve run your sensor data through a sensor fusion engine, that data needs to be in a format that your AMR’s control systems can understand and use. So, you’ll need to do some work to make that happen. You need to either build, or make use of an existing, interface.
That interface needs to be flexible enough to take data from a wide variety of sensors and prepare it for a wide variety of uses. And to build an effective interface you’ll need a driver that will take the localisation data from your sensor(s) and translate it into a format that the robot control stack can use. You can build a driver yourself, though depending on your network setup, your sensor manufacturers may have drivers and/or decoders that you can make use of straight away.
Interfacing in action: the OxTS ROS2 driver
In an AMR using an OxTS INS for localisation data, you can use our ROS2 driver to interface between the INS and platforms built using the ROS2 framework. ROS2 is a common framework for mobile robot development, as is the older ROS1 framework, and both are used throughout the entire robotic stack.
An OxTS INS outputs data using a proprietary message format called NCOM; the ROS2 driver decodes NCOM and transforms it into ROS messages that are usable by the robot’s control stack.
Because the driver is working with NCOM, it can pass a wide variety of data types to the robot, including covariance (confidence in the accuracy of the data). It can also translate a wide variety of reference frames into the formats supported by the ROS2 framework.
There’s also an open source ROS1 bridge, that lets you convert the ROS2 messages from our driver into ROS1 messages. That means you can include both ROS1 and ROS2 compatible components in your AMR and still have them all communicate to each other successfully.
So, if you’re not using an OxTS INS and your sensor(s) don’t have a similar ROS2 driver, then you will need to code something like that yourself.
OxTS ROS 2 Driver:
The OxTS ROS 2 driver, developed and maintained by OxTS, is available here:
Download ROS 2 driver
ROS 1 driver:
For ROS 1 compatibility, a ROS 1 driver developed by Dataspeed Inc. is available here:
Download ROS 1 driver
What if you dont use ROS2?
If you don’t use ROS2, then all the principles of what we’re saying are the same – you just have to find, or create, a driver to translate your sensor data into whatever framework you are using. If you’re using OxTS, for instance, you can use our ROS1 driver, and we also have a C decoder so you can translate NCOM data packets into a format that can be used within C code.
Autonomous Robot Navigation Solution Brief
AMRs need a robust robot localisation solution; a tool that not only records the position and orientation of the robot, but also operates both indoors and outdoors.
This solution brief steps through the aspects we recommend our customers consider when deciding on their source of localisation for their autonomous mobile robots.
Read the solution brief to learn how the right robot localisation solution can help your AMR project, including the key questions you need to ask yourself before embarking on a project.
Happy interfacing
We hope you enjoyed this blog and it’s helped you if you’re just starting out on your AMR journey.
If you’d like to learn more about what we can currently do for AMR engineers, view our application page.
Alternatively, if you’ve got a specific project that you’d like to talk to us about, contact us using the form below. We’re always excited to discuss the latest and greatest robotics projects.
Keep an eye out for the next blog in our series: beyond localisation
