Selfbuild LiDAR quad - Building and testing

Racing Quads, Self-builds & FPV
1

A few people might have seen the 7" long range drone I’ve posted here a few times before. It’s always intended to be a survey platform eventually, and originally, I was going to strap a Sony A7 to the bottom of it. However I got carried away and won a 360-degree LiDAR off eBay which is coming over from the US, one of these to be specific:

It’s going to be a fairly long journey to get it all working so thought I’d actually remember to start a thread at the beginning this time.

Building a mounting platform and integrating it will be about 1 kg in extra weight, thankfully it’s very low power (8W) so that’s a negligible addition.

The current flight platform is:

Frame - iFlight XL8 (?)
Motors - Tmotor F90
Props - Dalprop 7056
FC - Matek H743 Slim
FCS - Ardupilot
ESC - Hobbywing 60A
RC - TBS Diversity Nano
VTX - Tmotor race VTX
FPV Cam - Runcam Splitcam 2

So to be prepared, I did the sensible thing and strapped a 1 kg lead weight to the bottom of it and flew it around the bedroom:

It was never a particularly quiet quad, but boy is it loud in an enclosed space with the payload. I did record the flight but the rooms a bit of a mess at the moment so apologies.

The prop wash is massive which drives a lot of the ‘bouncing’ behaviour you see as it messes with the barometer. It’s a problem I’ve seen in the past, and it clears up about a metre above floor so not a big issue in the real world. Hover is about 40% throttle on the controller, so plenty of headroom seriously impressed by the performance of the motors, they are barely warm to the touch.

It draws about 15A from a 6S to hover (it’s about 6A without the payload) so flight time will be limited, probably about 10 mins, but at 300,000 data points a second it doesn’t particularly matter.

I’m using a 4500 mah 6S LiHV battery for now, but I am considering some high discharge 27100 batteries like the Samsung 50S’ cells instead, which would be slightly lighter, and an awful lot cheaper (£30 per 6S pack vs £60ish)

8 Likes
2

Tagged to WATCH this :+1:

2 Likes
3

Didn’t hit the bicycle :sweat_smile:

4

Nice project! Do you how much the Pucks are new?

5

It’s a bit hard to find that info, but from what I know at least back when they released about £6500 ($7999 usd is the exact number I’ve seen), and then they halved the cost a few years back to about $4000

6

This is one of my dream projects. I will be interested to read any build logs you post.

One day i would love a self build with FLiR and LiDAR. A surveying one stop shop. Something that can do ground surveys, forest surveys and everything in between.

1 Like
7

Exciting times, the LIDAR arrived and I’ve finally had time to wire up the power and Ethernet to test it, and it’s fully functioning!

Was a nerve-racking moment to first power it up as it uses a plug connection that I couldn’t see the wiring on and had to trust that no one had messed with it during it’s lifetime.

I’ve got a simple PCB coming from jlpcb which will let me tidy up the wiring, add an inline fuse, and cleanly interface with the PDB I have purchased to power it. I was originally planning to just use a 12V BEC, however I ended up ordering this:

Having a separate set of 5V, 12V, and VBAT connections that I can have in a junction box for the LIDAR will make life a lot easier, as it will be self-contained and can run the LIDAR (12V), and the Raspberry Pi and GPS (5V) and will make it a plug and play payload (we might run this on a USV at some point so thats a benefit)

Long and slightly technical text below about high precision time stamping

Sadly my eBay INS find isn’t playing ball and talking to the software (or any software for that matter), don’t think it’s broken, but there’s something off with the serial link. Until this is resolved, I can’t really drone mount it. However, there is an alternative solution which is to use the drone IMU’s which, whilst comparatively inaccurate, will give some attitude correction which can be further improved by closed loop SLAM techniques.

Unfortunately, IMU’s are crazily expensive (for industry grade ones you can be looking at 5 figures and up, 4 on the lower end) and angular errors are a nightmare, a 0.1 degree error over 100 m range will give you 17 cm of uncertainty in the final point position,a good commercial IMU will be considerably better at about 0.03 degrees but thats out of reach here.

Using the drones IMU comes with another issue though. TIME. We don’t normally think about, or care about, clock drift in our drones. DJI for example, just take the time off your phone which is normally out by several seconds, ardupilot will time sync over MAVLINK and is good to under a second, but by LIDAR standards that’s rubbish. The VLP-16 LIDAR I have fires a laser ever 2.304 μs, to time sync its data accurately we use PPS, time pulses (which are just voltage spikes) from a GPS chip that are sent along with the ZDA message to precisely timestamp them. There’s almost zero latency with the voltage spike compared to decoding a message so they’re a lot more precise, in the sub microsecond range. This is key as without this, the logger just timestamps the data as when it was received, when we need to have it timestamped for when it was sent instead, when you’re talking about 300,000 data points a second that tiny time shift really matters.

My GPS outputs a PPS spike (most do, it often gets used to blink the LED that shows you have a position lock), my proper (but not working) INS takes a PPS spike, and the LIDAR takes a PPS spike. The FC for the drone, doesn’t take a PPS spike (I mean it could an any analogue pin, but actually applying it is not part of any FCS I know of) so any motion data I have won’t be timed accurately enough to make good corrections. I’d also rather have a fixed reference frame between the LIDAR and the motion correction source, which I won’t have in that case)

With that in mind, I’m going to give it a go, and see how well it performs, but also keep my eBay search alert active in case another old used INS comes up. There are ‘cheap’ Chinese alternatives, but again all the affordable ones massively overstate their real precision, and don’t take that all important time pulse.

1 Like
8

Do you have to run the timer through the FC? I admit to expecting you to run a RPi to handle the entire imaging/scanning side of things and then maybe use Network Time Protocol to deal with clock skew. Is NTP not precise enough? Possibly hand off the data from the RPi to a vehicle mounted server. So you have an intermediate system doing data acquisition and handling, which then hands it off to the ground station server that does all the hard work.

Hmm, re read your post again and you are doing some of that. :slight_smile:

I am not an expert on this sort of stuff, by any means (in fact very far from it). My IT experience lies more in networks and other things. :slight_smile:

1 Like
9

So there’s a NanoPi (sort of like a PiZero but with a bit more grunt) which handles all the data logging for the imaging side, like you say. That sets it’s internal time from the GPS messages, but generally, its internal time shouldn’t actually matter because of the below:

The idea typically with survey networks is that ideally everything on the network sends data with embedded timestamps, the logger PC should not be timestamping any of the data itself as this is considered to be inaccurate. The killer is not so much a constant latency, you can normally correct for that, but since it will take a different length of time it takes the PC to decode the message each cycle (depending on what else is running at the time) it can cause all sorts of issues.

Generally with photogrammetry it doesn’t matter, even if you take 1 image a second you’ll be in a close enough ballpark. However, here when we’re talking about 300,000 measurements a second from the LIDAR, 10 measurements a second from the GNSS, and 100-500 a second from the INS.

For reference, I booted up some survey software for marine work (which I’d love to run on the drone, but the licence is £££££ and it only runs on Windows), with the GPS attached through a USB serial adapter, I settle around 12ms on the time error with nothing else running at all.

image
image3338×1131 629 KB

Which as you can see, the software is NOT happy about (below 10 ms is amber, and I believe below 3 is green). 10 ms means that plausibly, any data over 100Hz can end up being out of order, or misaligned. Would it probably be fine for a proof of concept, yeah, would it annoy me to know that potential issue was sitting there waiting to cause problems at the worst possible time, also yeah :laughing:

10

So what’s the solution? Build your own hardware specific to the task? Is it limited by the Pi?

Man I can tell you it would annoy me and I would spend a lot of time trying to fix it. But for me it would be understanding what the bottleneck is.

  • Is it hardware? If it is, can I upgrade it to use faster hardware.
  • Is it the interlink between hardware (LiDAR) and RPi? If it is, can I move to a different interlink, maybe Fibre.
  • Is it software? Do i need to write my own or employ a software house abroad to build me something custom.

And so forth. Troubleshoot, change, assess, rinse repeat.

I admittedly still have this process to do as I don’t even have a LiDAR sensor yet, nor a drone capable of carrying it. Maybe in a year or two when i have spare money to blow on a possible folly. :slight_smile:

1 Like
11

TLDR - This link explains the two approaches pretty well:

https://confluence.qps.nl/dm/help-utc-driver-35594191.html

PPS is the solution, you can actually get specialist PPS adapters which will let you time sync a pc that accurately (but again they’re expensive) but it’s not normally needed.

The LIDAR timestamps all its own data using the PPS signal you give it, and so is accurate to the microsecond.

A good INS/IMU/AHRS will output TSS1/TSS1 (as well as a proprietary format normally) which is UTC capable, which means with every packet of data it sends the timestamp for that data with it, the INS itself is also receiving that same PPS time spike (you actually get multiplexers for this which let you split out the PPS, but you can also just splice out another wire and it’s generally fine).

At the end of this day, this means all the data reaching the logging PC has the format

TIMESTAMP | DATA | CHECKSUM

So instead of your logger assigning time to the data based on when it arrived, it just decodes the (accurate & synchronized) timestamp that got sent along with it, hence no problem if the PC time is out of sync a bit, or not as accurate.

Basically, the solution is to not be a cheapskate. Drop £1000+ on your INS/AHRS and you won’t have an issue.

For the actual data logging, the best way is just to capture the network packets then you can replay/decode them at will in whatever software you pick back on the ground (of which there are many options) where weight isn’t an issue, or write your own, as all the time data is already stored there.

12

Someone actually has PPS working on a Raspberry Pi (since we have analogue sense pins readily available), so if I end up going with a cheaper IMU, that will be my solution. I’ll have to suck up some latency, but hardware serial is generally also better than USB-Serial.

I’m using a NanoPi NEO Air (Raspberry Pi Nano’s are still like gold dust, the only place I have ever managed to get them is the physical store in Cambridge, and I’ve run out of people to send in to buy one) which has the upside of 2 usable serial ports, so 1 for the GPS, 1 for the IMU, and the LIDAR is over Ethernet.

13

I’m away at a conference this week and happened to stumble across the same lidar, on a commercial solution. Wouldn’t want to be getting too close to that, but a seriously impressive piece of kit with lots of extras bolted on too!

IMG_20221212_172222
IMG_20221212_1722223000×4000 4.35 MB

1 Like
14

image
image1624×1269 263 KB

Finally got round to designing the PCB to handle all the connections between the sensors, been sent of to JLPCB so hopefully in a month or so I can start wiring it all up!

I have designed the junction box, but for the smaller original PCB, not this new extended one. So back to the drawing board with that one, going to have to change how things are arranged to fit it all in, but this way saves a lot of wiring.

2 Likes
15

I remember making pcbs at home. Swishing it in ferric chloride. Good days

16

I’ve always wanted to give it ago, and I’ve seen people using 3D Printers to trace the masks which is a cool idea. But it’s so inexpensive to get them made, like £5 for a dual layer PCB tested and shipped to your door in about 20 days, I couldn’t even get the chemicals for that price!

1 Like
17

I didn’t realise it was that cheap!

18

image
image1904×714 81.8 KB

$11 (£9ish) for 5 each (minimum order) of two different PCB’s, it’s $4 per design + $3-4 postage normally.

2 Likes
19

All the sensors now wired up and time synched together. All I have to do now is finish the housing design (part way there, just need to figure out the mountings), and get a NanoPi set up to log everything!

IMG_20230131_180407
IMG_20230131_1804074000×3000 1.76 MB

2 Likes
20

stumbled across this one, thought I’d get a seance going and see if this one went anywhere?
@Bobbysmile … how have you got on?