Object Avoidance with Dijkstra

Dear all,

I am working on object avoidance.
It seems that Bendy Ruler works perfectly!
But, the Object avoidance with Dijkstra keeps failing to find a path as shown in the below.

To resolve this issue, I increased OA_MARGIN_MAX. However, it did not help at all.
Could you help me to solve this problem?
Thank you in advance!

  • Testing environment:
    param set AVOID_ENABLE 7
    param set FENCE_ENABLE 1
    param set FENCE_RADIUS 10000
    param set OA_TYPE 2
    param set OA_MARGIN_MAX 10

  • Testing mission

  • Log

@KimHyungSub,

The issue is probably that some point are outside (or inside) some of the fences. The one that may be tripping you up is the circular fence because it doesn’t appear on the map. see FENCE_RADIUS.

2 Likes

Hello @rmackay9,

He assigned 10,000 to the FENCE_RADIUS.
In such a case, the circular fence set by the FENCE_RADIUS still can make the rover stuck?

@Benjamin,

Another possibility is that the target point is inside one of the exclusion fences. I’m not sure of the exact issue but I’m pretty confident that Dijkstra’s is working correctly so instead of diving in I’m hoping @KimHyungSub can do some more analysis on his own. Maybe start with a simpler set of fences and confirm it works, then increases the fences until figuring out which one causes a failure.

Can you also send your obstacles file?

Hello @rmackay9 @manavgandhi17,

I could reproduce this issue by using this mission and obstacles file.
All waypoints were outside of the exclusion fences.

The rover was stuck in a location before reaching waypoint 2 as shown in the below.

Edit: I could also trigger this issue in a more simple fence than previous one.
There was only one fence, and the rover was stuck in the same location as previous one as shown in below.

@Benjamin,

OK, I think the issue is that simple avoidance is stopping the vehicle when it reaches the edge of the circular fence. Could you try turning off “simple” avoidance?

I think it is probably this issue.

1 Like

Hello @rmackay9,

Yeah, that’s good point!
I could not reproduce this issue anymore after disabling “simple avoidance”!
Here, one lesson is that users need to turn off the “simple avoidance” when they want to use Dijkstra as a object avoidance path planning.
Could we explicitly mention such parameter setting in document? I thought that assigning 0 to “AVOID_ENABLE” disables object avoidance. Also, enabling the “simple avoidance” does not lead to any problem if users leverage BendyRuler. Thanks!

At the same time, I’m not sure what advantage is afforded by enabling simple avoidance when using BendyRuler. Is there any?

@Yuri_Rage me and Randy have often thought about Simple Avoidance being the second layer of defence… incase BendyRuler/Dijkstra fails… Simple Avoidance is activated and stops the vehicle

1 Like

Hello @rishabsingh3003
Yes, two layers of object avoidance is a good design choice!
It is also worth mentioning that if the simple avoidance acts as the second layer of collision prevention, disabling the simple avoidance and enabling Dijkstra is weird.
The simple avoidance always need to be disabled because turning on the simple avoidance and Dijkstra leads to an issue as mentioned @KimHyungSub.

I don’t think the Dijkstra’s + Simple avoidance issue will always have this issue. For example it may only happen if circular fences are used. The fix/improvement that we need is for Dijkstra’s to choose a path that is a little further from the fences… maybe it needs a configurable margin.

1 Like

Hello @rmackay9,

It would be great if ArduPilot provides the configurable margin :slight_smile:

2 Likes

In my case Dijkstra either breaches the baundary or does not know where to go at all. For the reference, distance between the lines is ~1m, smaller fence circles - 2m radius.

Here it avoided 1st fence, but struggled a few times and cound not find a way around the next one and eventually breached the fence:

After manually driving out of the fence, same happened on the 3rd fence:

This occurs with AVOID_ENABLE = 1
If it’s disabled, it is more “brave” and still tries avoiding the fence, yet ocasionaly goes right through it and then sets on HOLD when it’s too late:

For the human eye all the fences could have been easiliy avoided, there was plenty of room. What can be changed to make it work?

FENCE_MARGIN = 1
FENCE_ACTION = 2 (hold)
FENCE_RADIUS = 3000
OA_MARGIN_MAX = tried 1-4
OA_OPTIONS = 1
OA_TYPE = 2

Here is another example of the weird route calculated while heading to WP 17:
took extremely wide route around one fence (4m radius) and ran straight into another fence:

FENCE_MARGIN = 1
OA_MARGIN_MAX = 4

Seing such behaviour it can’t be trusted at all

This just looks like bad tuning on the rover control. I use Dijkstra all the time on my multirotor and it works every single time. You need to fix how well your rover pathing is to ensure that it can meet the required pathing created by the avoidance algorithm.

Made some tuning, yet it still stops in these situations. My guess that this happens when one of the heading lines crosses the fence circle or fence margin. In either case what could be done to avoid that?

What’s even more confusing to me, that in the below situation it couldn’t make into the WP#8, eventhough on the earlier circle (you can see the blue route it took) it avoided the same fence succesfully while heading 3->4:

Hello,

I use object avoidance with OA_TYPE = 3, and set avoid_enable = 0, but sometimes it also holds. However, I found when I set OA_TYPE = 1 with bendyruler and other settings are the same, it can go through. So, if I want to use OA_TYPE = 3, what I can do to avoid hold?



@rmackay9 is there any way to use Bendy ruler for exclude fence in OA_Type = 3,

I’m not sure what your goal is, but I think this might satisfy intent:

FENCE_ENABLE,1
OA_TYPE,1
OA_MARGIN_MAX,2
OA_BR_LOOAKAHEAD,5

Set OA_MARGIN_MAX and OA_BR_LOOAKAHEAD to reasonable values for your use case. I used 2m and 5m for this demo. You can set them to lower values to “hug” the fences a little closer as needed.

Set FENCE_RADIUS large enough to cover your area of operation.

All other fence and avoidance parameters set at default values.

SITL behavior after setting these parameters:

image


For my own use case, I prefer OA_OPTIONS,0 so that the vehicle returns to the original path. I also set WP_OVERSHOOT,1 for this example (which is lower than the SITL default of 2):

image

1 Like