Making a LiDAR – Part 2

The Holistic Design Problem

By: David
Principal Consultant, Data Exploration

9th April 2019

3 minute read

Home » Insights » Making a LiDAR – Part 2

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.

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.

Further Reading

Top