As you may have seen in my previous post on The Luggage I’ve been hard at work rebuilding it anew and adding new features. I mentioned I wanted to have basic control as soon as I switch it on, this had to include safety features to prevent it running in to obstacles, either stationary objects or people. I don’t want it to gain it’s namesakes reputation after all.
In this post I’ll explain how I fused data from four LIDAR scanners with the aim to simplify usage in obstacle avoidance and increase safety of the robot.
Since the inception of this project the cost of LIDAR scanners has dropped to an almost laughably low price, so seemed rude not to take advantage of this. Enter, the OKDo LIDAR, which even at £50 is pretty cheap, however if you look on eBay you can find them for £12 each. I linked to RS as it’s a page less likely to disappear than a random eBay auction.
These scanners are cheap enough I bought one for each side of The Luggage, I figured they would make excellent safety curtains as in basic mode I could just program the motor controllers to enable the brakes if anyone or thing got too close.
For those not familiar with LIDAR scanners they are simple in concept, they have a spinning laser range finder and they output data for 360 degrees over serial. This is a 2d LIDAR as it provides distances on a plane around itself, imagine a RADAR screen from pretty much any movie or show you can think of and it’s the same concept. You can get 3d LIDAR scanners however they are eye-wateringly expensive.
Output from these is essentially key/value pairs of angle and distance, you get luminosity data for each point too which tells you how strong a signal it was based on. You can use this for simple filtering as a strong return could have higher confidence than a weak one for example.
As I want to have a basic operating system for this robot running on microcontrollers I thought about how I may be able to simplify the setup to reduce the processing cost on the motor controller. With four LIDAR scanners outputting at around 250kBps that has the possibility of swamping an MCU with data, so I thought I’d dedicate one to the task.
I created a simple rig using a cardboard box to mount four of the scanners with an object between them to simulate the body of the robot. I connected the outputs of each to the hardware serial inputs on a Teensy 4.1 and wrote some code to transform the polar coordinates provided by the scanner in to cartesian coordinates relative to the centre point of the box.
This fused dataset is then output over USB serial to the host, but importantly can also be output to one of the other hardware serial ports to be used by another microcontroller. In the image, above, you can see the data visualised in a simple Unity application I threw together for debugging.
The result of this is that I can output a stream of data with (x,y) coordinates, this allows another microcontroller the much easier task of “if object less than X or Y distance, stop” rather than having to calculate this itself from the raw data.
In the image above you can see solid lines in multiple colours showing how the same objects were detected by a few of the scanners, they don’t perfectly overlap but it was good enough to prove the concept as it mapped nicely to the layout of my living room. It did suffer from some strange circular artifacts around the centre which pulsed in and out, this is a problem for Future Keegan, he loves things like that…
Going back to the concept of simple behaviours on power-up and extending with compute, the Teensy also has the option to output raw data on a second virtual USB serial port. This would allow me to utilise the raw data from the sensors with existing tools and packages, in ROS for example, as a simple node would be able to split the four raw streams in to separate ROS topics.
If you want more detail on how I implemented this, baring in mind it is only a proof of concept and shouldn’t be considered functional, feel free to have a look at the code here.