Making a LiDAR – Part 2

The Holistic Design Problem

By: David
Principal Consultant, Data Exploration

9th April 2019

3 minute read

Home » radar » Page 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.

Making a LiDAR – Part 1

LiDAR Mechanical Aspects

By: David
Principal Consultant, Data Exploration

8th April 2019

3 minute read

Home » radar » Page 2

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.

In concept, a LIDAR scanner is a rather simple way of making 3D scans of a physical environment. 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.

EW BrightSpark, James Henderson One Year On

James Henderson - Consultant, Antennas & Propagation

By: James Henderson
Consultant, Antennas & Propagation

27th February 2019

Home » radar » Page 2

Following the BrightSparks award ceremony in May last year, most of my work has been on developing an electronically-scanned radar unit operating at mm-wave frequencies, applicable to autonomous ground and air vehicle monitoring and control. This has been a particularly interesting and challenging project as the design has been driven by a demanding requirement to create a small, low power, high performance sensor.

The key area of innovative design that I am particularly proud of is combining two 48-element antenna arrays on to the same PCB as the electronic circuitry. To achieve a low cost, the arrays are realised through a combination of 3D printing and PCB techniques.

This development posed many technical challenges owing to the often conflicting PCB-related requirements of antenna and RF circuitry. However, integration and performance benefits make this approach worthwhile.

System calculations

Initial work on this project required comprehensive system calculations to exactly understand the design requirements. System level planning is informative when determining how to distribute the required tasks.

Often, a number of subsystems could potentially solve the same technical challenge but only when looking at the problem as a whole can you assess how the elements of the system can best work together.

Scanning the radar beam

A key aspect of the design was how to scan the radar beam. In a previous project the antennas were mechanically moved to build up a 3D view of the scene. In contrast the new requirement was to scan the antenna beams electronically, which has many advantages over mechanically scanned systems. Electronic beamforming can be implemented digitally, at the analogue front end, or even within the antennas themselves.

In this design, the scanning mechanism was an integral part of the antenna array, which significantly simplifies other aspects of the system leading to a small sensor having low power consumption. However, this approach required lateral thinking when designing and constructing the PCB to achieve the target performance. For the first iteration of the design the electronics worked as intended, but the antenna performance was lower than expected.

Further investigation revealed the reason for the drop in performance and emphasised the many and varied challenges associated with working at mm-wave frequencies.

Special Interest

The second design iteration gave performance closely matched to my system calculations. This confirmed that the design operated as intended, which was extremely satisfying.

This whole process has exposed me to some particularly interesting design work and has consequently encouraged me to initiate a Special Interest Group within Plextek that specialises in the design and development of mm-wave electronic systems.

Following this project I expect to see substantial interest in operating at mm-wave bands, enhancing the capability of mm-wave circuits and I’m excited to be working with these cutting-edge technologies in the future.

The CEO of Plextek, Nicholas Hill, added:

“BrightSparks is a fantastic way to show your employees’ work is valued. It’s so important to get young people enthusiastic about their engineering careers and award recognition is a great motivational boost. The BrightSparks award last year won by James Henderson was well deserved and he has continued to shape his engineering career by contributing to key company projects here at Plextek.”

Following the BrightSparks award ceremony in May last year, most of my work has been on developing an electronically-scanned radar unit operating at mm-wave frequencies, applicable to autonomous ground and air vehicle monitoring and control. This has been a particularly interesting and challenging project as the design has been driven by a demanding requirement to create a small, low power, high performance sensor.

The key area of innovative design that I am particularly proud of is combining two 48-element antenna arrays on to the same PCB as the electronic circuitry. To achieve a low cost, the arrays are realised through a combination of 3D printing and PCB techniques.

This development posed many technical challenges owing to the often conflicting PCB-related requirements of antenna and RF circuitry. However, integration and performance benefits make this approach worthwhile.

System calculations

Initial work on this project required comprehensive system calculations to exactly understand the design requirements. System level planning is informative when determining how to distribute the required tasks.

Often, a number of subsystems could potentially solve the same technical challenge but only when looking at the problem as a whole can you assess how the elements of the system can best work together.

Scanning the radar beam

A key aspect of the design was how to scan the radar beam. In a previous project the antennas were mechanically moved to build up a 3D view of the scene. In contrast the new requirement was to scan the antenna beams electronically, which has many advantages over mechanically scanned systems. Electronic beamforming can be implemented digitally, at the analogue front end, or even within the antennas themselves.

In this design, the scanning mechanism was an integral part of the antenna array, which significantly simplifies other aspects of the system leading to a small sensor having low power consumption. However, this approach required lateral thinking when designing and constructing the PCB to achieve the target performance. For the first iteration of the design the electronics worked as intended, but the antenna performance was lower than expected.

Further investigation revealed the reason for the drop in performance and emphasised the many and varied challenges associated with working at mm-wave frequencies.

Special Interest

The second design iteration gave performance closely matched to my system calculations. This confirmed that the design operated as intended, which was extremely satisfying.

This whole process has exposed me to some particularly interesting design work and has consequently encouraged me to initiate a Special Interest Group within Plextek that specialises in the design and development of mm-wave electronic systems.

Following this project I expect to see substantial interest in operating at mm-wave bands, enhancing the capability of mm-wave circuits and I’m excited to be working with these cutting-edge technologies in the future.

The CEO of Plextek, Nicholas Hill, added:

“BrightSparks is a fantastic way to show your employees’ work is valued. It’s so important to get young people enthusiastic about their engineering careers and award recognition is a great motivational boost. The BrightSparks award last year won by James Henderson was well deserved and he has continued to shape his engineering career by contributing to key company projects here at Plextek.”

 

 

Plextek and Wave Tech Partner to Revolutionise Airport Runway Safety

Nick Koiza, Head of Security Business features in ‘Counter Terror Business’ magazine this week. He discusses Plextek’s recent collaboration with RF signal technology company, Wave Tech on a foreign object debris detection radar that has the potential to save lives.

To read the full article on page 10 please click here.

For more information, contact Nick via nicholas.koiza@plextek.com

By Marcus C. Walden

Abstract: This paper describes the design and characterization of a frequency-scanning meanderline antenna for operation at 60 GHz. The design incorporates SIW techniques and slot radiating elements. The amplitude profile across the antenna aperture has been weighted to reduce sidelobe levels, which makes the design attractive for radar applications. Measured performance agrees with simulations, and the achieved beam profile and sidelobe levels are better than previously documented frequency-scanning designs at V and W bands.

Read more…