Selfbuild LiDAR quad - Building and testing

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)

6 Likes

Tagged to WATCH this :+1:

2 Likes

Didn’t hit the bicycle :sweat_smile:

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

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

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

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.

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

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.

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:

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

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.

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.