Copter Object Avoidance with upward facing lidar

A demonstration of object avoidance using a single Lidar pointing forward or upwards.

The vehicle is my elderly IRIS and in the first test the LeddarOne lidar is attached facing forward. Much like the tests with the SF40C the vehicle was able to stop 2m from the hedge. Ideally a wide beam Lidar or sonar would be better to reduce the change of the beam getting through the hedge.

The second test is in a garage. The vehicle is flown in AltHold mode and the throttle is held up. The vehicle senses the ceiling and stays 2m below it. With a little more work this feature will hopefully be good for tunnel and bridge inspection.

For those interested in more details, I’ve written a wiki page on our Object Avoidance feature which is a good starting point especially if you want to add support for new sensors or get involved in the development.

In case you haven’t heard, we also support the TeraRanger Tower now for object avoidance.


This is great and I believe the first simple object avoidance system that can easily be used on Arducopter.
What are the recommended cheapest LIdar modules we could get today ?

1 Like

Excellent work here.
Can I ask if the LidarLiteV3 has been tested with ArduPilot and does it work?

I’ve had issues with Lidar systems detecting vegetation differently which lead to noisy readings that I suspect to be scattering in the water molecules. I updated code from a developer fork for a parallax lidar sensor application and experienced the same vegetation issues despite that it wasn’t a full spectrum sensor. Even with filtering I could not remove the high frequency components I modeled as “hedge gaps”. I also tried different densities of canopy/vegetation but it could have been the sensor or my code. I was using the "Black Label " Lidar Lite and it did not look like i2c interference (I used PWM input). I tested the code without the vehicle to ensure there was no interference.

Thank you for all you have done!

very interesting.
I’m using VRBRain and LidarLite V1 for altitude control (using PWM) and I’m planning to use same sensor via a Companion computer as obstacle detection and avoidance (actually stop).
But if under evaluation to include directly on APM code, I think it is much better: so please add LidarLite v1 into the testing (better if via PWM and not I2C because I have all ports already used ;-))

1 Like

Hello rmackay9,

At the Object Avoidance with SF40c video, it’s written that avoidance code configure to ignore vehicle’s legs, can you instruct me to how do implement it as well?

Thank you very much

Did you connect the sensors directly to the FC or did you use an intermediate computer (i.e. Arduino) which then provides a MavLink message?


The sensor is directly connected to the FC. It’s documented on the SF40c wiki page:

Sorry I missed your question. With AC3.5.0 (which has just been released), there are a bunch of PRX_ ignore parameters which allow setting up areas to ignore.
Hope that helps a bit, thanks for using ArduPilot!


I also tried to connect 2x Lidar Lite V3 lidars via the i2c hub put I seems like it is not possible, since you cant change the i2c address. At least I havent found a way to do so.

The manual also states that: "The I2C address will be restored to default after a power cycle."

That doesnt make any sense to me?:thinking: Why would they make the I2C address return to default? Any ideas?

Thanks :slight_smile:


What you have to do is to drive each Lidar power enable pin (pin 2) with a dedicated GPIO set to low (power shutup). Then you enable the first device, by raising the corresponding GPIO to high and set the desired address. Next, you repeat this sequence for each additional Lidar on the bus.

That is the way I make it work on the POC with 6 VL53L0 :

Okay, thanks for the idea! That seems like a legit solution.


  1. you need an intermediate computer (like arduino or any other µC) to to the polling. If you are only using 2 lidars (like I am) thats seems like a bit of “overkill”.
  2. I would assume the startup time of the lidar is not as good as the response time via I2C. That pobably limits your refresh rate.
  3. why not use the full capability and “cleanliness” of the I2C interface (only 2 wires, supported by hardware, …) no extra select wires( thats what really sets I2C apart from other interfaces, say SPI)

There are probably a lot of other solutions, like the one you presented, and they all work. (I ended up using one Lidar via PWM and one via I2C)

I just dont get, why they would not allow you to permanently change the I2C address. That would make everything so much cleaner and easier. (also when using it with other electronics, like I intend to). It just doesnt make any sense to me! :frowning:

However, thank you very much ppoirier! That is a really nice project and inspiration! :slight_smile: I really like the idea of not having any moving parts!

1 Like

Using different interfaces (PWM & I2C) do really solve your problem , necessity is mother of ‘‘solutions’’ :slight_smile:
And yes, adding a dip switch or solder pads would make life easier. I suspect that a permanent memory was not a good economic option with the FPGA .

BTW It would be really interesting comparing the speed and accuracy between the PWM and the I2C, if you find anything of interest, feel free to let us know.

sure yes. I will maybe do some bench tests if I find the time :smile:

For now, mounted on the aircraft itself, they both seem to work just fine. It is just a bit annoying having to fiddle around with the extra wires. :roll_eyes: Or maybe I am just a bit picky, haha.

Also, here are some photos of my current setup. If anyone is interested :wink: :

(Click on the photo to see the rest of the photos)

On the first photo you can see the cable I used to connect the lidar to the I2C hub. I added a smoothing cap (470uF) in order to provide a stable voltage to the lidar / prevent voltage spikes.

On the second photo you can see the I2C hub. I connected an external 5V BEC via the red JST connector and disconnected the power cable on the connector coming from the Pixhawk so the BEC would not fry the Pixhawk or vise versa.
And there is also one lonely connector missing its plug. :grin: The lidar intended to go there is currently connected via PWM.

On the other two photos you can see one forward pointing lidar and one pointing downwards. Next to it is the PX4FLOW optical flow sensor.

If anyone has any questions feel free to ask or send me a PM. :slight_smile:


1 Like

Looks pretty good to me ,
FYI, I made a DIY I2C bridge with pull-up resistors & Capacitor: How to connect Lidar Lite v3 to Pixhawk PWM?

Fabian , this is a all wood quad you made ?!?!
That would deserve a BLOG :slight_smile:

two questions (mainly to @rmackay9):
I see on PRX_Parameters that it is possible to define “MAVLink” as proxmity sensor, what does it mean? which is the MAVLink message to pass to FC? I have a Companion computer (e.g. RPi3) to which I’ve like to connect the sensor (Lidar Lite or similar) and from companion to send proximity info to FC.

Value “4” for PRX_Type refers to “RangeFinder”, which rangefinder? Can I use LidarLite connected to FC via I2C?


Interesting things you work with.
I plan to build a Y6 with vertically installed Slamtec 40m to map nearby power lines and shrubs and trees.
Is it possible to use any of the collected data? Thinking on the data that indicates the wire’s position, and let the drone follow the lines at a constant center and height above the wires?
Hope someone has some constructive thoughts on this arrangement?