Making a LiDAR

By: David
Principal Consultant, Data Exploration

8th April 2019

3 minute read

LiDAR mechanical aspects

In concept, a LIDAR scanner is a rather simple way of capturing 3D scans of a physical environment, and in this series of 5 blogs I’ll take you through my various thought processes in building a working LIDAR prototype. In our LIDAR prototype, we will see if we can use a GARMIN laser range finder sensor to build a working LIDAR. We will spin the range finder on its azimuth, and after each complete revolution, we will nudge it slightly to point upwards at increasingly steeper angles. At the same time, we will continually capture the measured distance data to the target. When the scan is complete we will have a data set called a point cloud that represents the distance from the LIDAR to every point in the room and that’s just perfect for rendering on an Oculus Rift VR headset. But, before we get ahead of ourselves, we have a few mechanical problems to solve first.

If you’ve seen the press hype about 3D printed firearms you might be surprised to hear me express 3D printer disappointment, and In fact, you might have expected a 3D printer to be my perfect “drawing board to the physical word” prototyping tool. But, I’d say the reality is rather different. It’s hard to say if my scepticism comes from the PLA filament unravelling, the shrinkage leaving questionable tolerances, the poor finish, or the print times in excess of 12 hours. Either way, I’m unconvinced by the results of consumer and light industrial 3D printers. So, we’ll build our LIDAR parts old school with a manual lathe and mill. (There is just one niggling point and very important points that we will come to later where we use a 3D printer to enable everything!) I should also add that my industrial design colleagues producing beautiful flowing curved case works may have a very different opinion to myself. For them, 3D printing comes into its own.

We’ve also got an electrical wiring problem to solve, and that’s because we need to get power and data to our range finder without our wires getting twisted. We’ve got three obvious choices on how to do this; we can spin 360 degrees and then unwind the wires by spinning the other way, or we can build a complicated inductive power system with RF\optical to carry data (no wires to twist), or we can use a slip ring (a slip ring works just like the brushes on an electrical motor). The first solution is ugly and will slow the scan down with all the stopping and starting. The second solution sounds robust, but it’s a design exercise in itself that adds unnecessary burden to our budget. Ideally, we’d rather not have that for a prototype. The third solution is quick, very low cost, but will eventually fail as the slip ring brushes degrade. None the less, even a low-end slip ring is rated 5,000,000 revolutions, which is more than enough for our prototype.

Our slip ring will need to fit through the body of a rotating shaft, and it needs to be mounted with screws that clamp the slip ring flange onto the shaft. There isn’t anything we can do to change the slip ring dimensions, so follow it through and the shaft diameter comes in at around 22mm. We’ll need the shaft to fit through bearings, and we want the shaft to rotate. We’ll do that with a timing belt and timing gear around the shaft.

The Holistic Design Problem

I’m tempted to say that designing software for a word processor is easy, and whilst many will quite rightly disagree, my point is that a word processor software architect doesn’t have to think about anyone other than themselves and a few well published APIs (and perhaps the user interface if we are lucky, but that’s perhaps the subject of a different Blog!). It all gets far more complicated when we are designing something with electronics and moving parts. That’s because we have a set of disciplines with circular dependencies. The mechanical design team need to understand the limitations and requirements of the electronics and software, but that’s hard to do until the electronics and software teams understand the mechanics. In other words, we have a chicken and egg problem to solve.

We are going to build our Lidar with a laser range finder, and we will want to spin the range finder around on the azimuth, and after every 360 degrees, we will need to bump it in elevation. We could use DC motors, we could use gimbal motors, we could use stepper motors, or we could even use servos. Whatever we pick, we can be sure that we face choices that make things easier for one discipline and harder for another. We need to make the choice that is best for the design.

Our electronic designers might decide that the simplicity of a DC motor is rather attractive, but we have to ask if our software engineers are going to be grateful when they have to start counting rotary encoder pulses to figure out how much a DC motor has moved. Equally, the mechanical engineers will thank nobody when they have to add a rotary encoder to the design. In fact, everybody apart from the electronics engineers will much prefer a stepper motor (the precise movement of a stepper motor is implicit, so they are great for applications like 3D printers). So, with that all said, we will make a decision for our Lidar and use stepper motors. We’ve made our electronics more complicated, but we’ve saved on software effort, we’ve simplified mechanical design, and we have reduced the bill of materials.

With the stepper motor decision made, the mechanical design can start. We can also start writing our embedded control software and designing our PCBs – or can we? If you’re familiar with embedded microcontrollers you’ll likely know they are software configurable with a multitude of different functions, and with a choice as to which, functions appear on which pins. So here is our cross disciple problem again; we need to make sure the software engineers don’t make a bad decision. A wrong software decision at that start could force our PCB designers to try and route four signal lines between two 0.5 mm pitch pins. Equally, a bad decision on pinout by the PCB designers might have subtle but severe consequences to our software engineers.

Needless to say, my examples are of course tongue in cheek, but I’m sure you’ll understand the point I’m making. It’s a really important concept that design needs to be multidisciplinary and that success only comes with cross-domain decisions made by people that understand the complete picture.

Embedded Software and Platform Choice

Do you remember as a child counting how long it took for thunder to arrive after the lightning flash, and then working out how far away the storm was? Well, a LIDAR uses the same principle but with light rather than sound. I think that’s amazing. Imagine switching a torch on, pointing it at the wall in front of you, and using a stopwatch to time how long it takes for the light to get reflected back to you. That seems ludicrous, but that’s exactly what our laser range finder is doing. (Did you know that one light Nanosecond is approximately one foot in length? So, I’m about 5.66 light Nanoseconds tall.)

Now, at the back of our laser range finder we have some wires that carry the measured distance data (I2C for the technically minded), so the first job of our software is to read the data, and just like a digital camera we need to write it back to an SD card. We also need to worry about controlling the scanning stepper motors. If you’ve no experience of stepper motor control, it’s quite straight forward; each time you generate a pulse the motor moves a tiny fraction. If you generate a continuous pulse train the motors spins. If you count the number of pulses you know how far the motor has moved. It’s all very straight forward, and just the sort of task a microcontroller was made far.

However, before we get started we need to pick a microcontroller, and this is where it can get contentious. Whatever you choose; somebody else will tell you that you should have done it their way instead. In my opinion, that’s frustrating, and they are usually wrong. I’ll defend that by saying only one thing matters. You need to pick a technical solution that’s within your capability to deliver to, and ideally exceed, the expectations of the people paying you. The great thing about engineering is that there will be many equally good ways of doing that, so you’re only wrong if your way isn’t one of them!

Personally, I’m not too keen on Arduino. It’s great for hobbyists and proof of concepts, but I do find its “simple educational” environment constraining. Likewise, the thought of days wading through thousands of pages of data sheets is equally unattractive. I want to write the embedded code to make the LIDAR work; I’m not interested in writing the code to make the microcontroller work. That’s why my own choice is the STM32 microcontroller family and the STM32CubeMx tool. It lets me “auto-generate” the framework to configure the microcontroller, I don’t have to read every minutia of detail in the datasheet, and it gives me a professional IDE development chain with full visibility of exactly what the hardware is doing if I should need it..

To sum up, with an STM32 I can get the job done, and I can meet all expectations. But importantly, if a BeagleBone running a Python interpreter lets you get the job done, and leads your customers to success, then don’t let anyone tell you that you’re wrong. Of course, don’t be closed to new ideas either. Learning and exploration are what makes life interesting!