Servers by jDrones

GSOC 2020 - Improvements to Object Avoidance, Conclusion

These three months, since GSOC started, have given me some great memories. I began my journey with bare minimum knowledge about the ArduPilot flight stack, with very basic bug fixes and some documentation as my only experience. Whereas now, I have multiple features, bug fixes, already merged in the Master. It wouldn’t have been possible without @rmackay9 @khancyr . I am grateful to them for guiding me through every step and making this period so comfortable by providing immense support through every “obstacle” (pun intended) that came in the way. Thanks a ton for this excellent opportunity, I could not ask for anything more!

Coming to the work done, ArduPilot’s Obstacle Avoidance features have had some significant changes. We completed more than what was initially planned and continue to work towards more improvements. I will be listing them down below so you can have a glance at what all will be coming in the next release. Hopefully, there is something that interests everyone!

Ardupilot has two main avoidance systems:
PathPlanning (for autonomous modes) and Simple Avoidance ( for semi-autonomous modes).

Path Planning:

ArduPilot has two Path Planning algorithms currently, BendyRuler and Dijkstra’s.

Dijkstra’s is a very famous algorithm, but Canberra UAV has developed BendyRuler, and the exact algorithm is relatively unknown. I have a blog post that explains the idea behind BendyRuler: GSoC 2020: Improvements to Object Avoidance in Rover & Multicopter

BendyRuler has seen a lot of changes in these past months:

  • BendyRuler has a new type of avoidance. Until now, it could only avoid obstacles by manoeuvring horizontally, but now you can also enable vertical avoidance, in which the vehicle will gain or reduce altitude to avoid the barriers.
    A live demo can be seen here:


  • One thing that most users who have experienced this algorithm would agree is that it is not reliable for large obstacles that suddenly appear in front of the vehicle. This happens because it has a hard time to decide between two equally good obstacle-free paths. To fix this, now the vehicle will try and maintain its chosen path for as long as possible. It will try not to switch over to an equally good course, which might be in the opposite direction to the current path. Therefore we try and avoid any big bearing changes unless this path is significantly better than the one we are on.

This can be seen here(before-left vs after-right):

  • The object database has now been turned 3-D. The presently released version of ArduCopter and Rover project the obstacle to be always in front. So if the vehicle was to pitch, or roll and see the ground “x” meters away, the object database would continue to think the obstacle is right in front of it “x” meters away instead of below it. This has now been fixed through some rotation matrices, and it makes a massive difference in the performance! A simulation can be seen here:
  • Another common problem with BendyRuler is that while taking off, the ground may be seen as obstacles which is then stored in the Obstacle Database. This can be very inconvenient, to say the least. The copter will now reject obstacles within a 3-meter radius of the home location up to OA_DB_ALT_MIN height. The parameter can be set zero in case the feature is not needed. This will immensely help with autonomous takeoffs.

There is an entirely new addition to path planning algorithms, that fuses BendyRuler and Dijsktras together.

  • A major drawback of Dijkstra’s is that (currently) it only works on fences. This is largely because if it was extended to support non-stationary proximity obstacles, we would need to rerun the algorithm every time an obstacle or the vehicle moves. This would require a tremendous amount of computational power, which would keep increasing as the number of obstacles increases (and so will the number of “nodes”).
  • Therefore this new type of algorithm will run both Dijkstra’s and BendyRuler at the same time and default to Dijkstra’s based navigation when there is no obstacle near the vehicle. This will make sure we have the shortest distance to reach the destination.
  • IF an obstacle is detected by a proximity (lidar) sensor, we will switch to BendyRuler (which is a ray-based algorithm) to navigate safely away from it.
  • This feature, therefore, takes away the headache of the user deciding which is the best path planning algorithm for their use case and automatically makes the decision for them.
  • A simulated demo can be seen here:

Simple Avoidance:

Simple avoidance has two options: Either stop the vehicle in front of the fence/obstacle or (for copter) try and slide across the obstacle. The way this works is that if a user is trying to push the vehicle towards the obstacle, the vehicle will try to “ignore” the velocity in the direction of the present obstacles. So simple avoidance at best, would reduce the speed in a particular direction, and never add anything to it. Therefore, the vehicle did not have that capability to maintain a margin from the obstacle, if the obstacle started to move towards the vehicle. This is no longer the case, and now the vehicle can maintain a margin (safe distance) from fences and obstacles in any combination. This has been tested very thoroughly in the simulators, in the absolute worst-case scenario I could think of. More detailed explanation, with live demonstration and simulations, can be seen here:

The exact code for each of these features can be found in the linked PR’s here:

  1. BendyRuler and Obstacle Database should see obstacles in 3D:
  1. Provide option to search for clear paths vertically in BendyRuler:
  1. Resolve BendyRuler’s hesitancy:
  1. Recovery from BendyRuler avoidance may impact the fence:
  1. Fuse BendyRuler and Dijkstras together:
  1. Back Away from the obstacles in Simple Avoidance:

Other minor improvements:

  1. Reject obstacles near home (easier autonomous takeoff’s:
  1. Bugfix with “Stop mode” never reaching the desired margin:

  1. Check if readings are valid before sending it down to Object Database:

  1. Check if the origin is set before running OA:

I would also like to thank CubePilot( @proficnc) and @MartyMcFly, who were very generous in providing me with hardware and funds. This enabled me to test all my features on a real vehicle, and the work I did would not have been possible without that. Many thanks to you!

The GSOC period is now over, but I will continue working with ArduPilot and hopefully come up with more features that might be useful to all the users. These months have been truly life-changing for me. Kudos to the ArduPilot community and the patient developers for making this a one of a kind experience for me! My gratitude goes towards you.


Awesome job and thank you!!

1 Like

great work! It is so satisfying to see these avoidance features being developed to such a great level

1 Like

Well done @rishabsingh3003 and congrats on completing your GSoC project! I’m really excited to see your work in action soon!

1 Like
Servers by jDrones