Servers by jDrones

BendyRuler Observations

I really like the Exclusion Fence capability in the latest version of ArduRover using BendyRuler.
I have a few observations that may be of interest. I am running ArduRover 4.1.0-Beta6. My parameters are set as follows:


  1. With the parameters set as above, the vehicle comes right up to the fence and then navigates nicely along the fence (a little squiggly but I can work on that) UNTIL it “sees” a clear shot to the next waypoint. Then if seems to immediately end the BendyRuler algorithm and return to normal navigation, which causes the vehicle to work its way back to the yellow line according to its tuning. I have looked at the code a bit (can’t say I fully have it understood at the moment), and I believe this is the planned behavior. This behavior causes the vehicle to miss some portion of the original waypoint line as shown here:

For many applications, this behavior is no problem. If, however, the desire is to traverse every part of the pre-planned route between waypoints (except within the fence), it isn’t perfect.

  1. I can place a waypoint on the downstream side of the exclusion fence on the original path and cause ArduRover to navigate to that point and get the desired coverage as shown here:

  2. Would it be possible to modify BendyRuler (or create a separate OA mode) so that when ArduRover encounters an exclusion fence, it inserts an internal temporary waypoint across the fence on the original path a short distance beyond the fence, basically internally doing what I did manually above? For a circular fence, calculating the position of the temporary internal waypoint would be relatively easy, I think. It would be straight ahead on the vehicle’s original path, a distance equal to the diameter of the fence plus some small distance to be sure the waypoint is outside the fence a sufficient distance to work well. For a polygon, the code would have to find the intersection between the fence and the original path on the downstream side of the fence and set a waypoint a small distance down the path.

  3. I did encounter a situation where ArduRover went into an infinite hunting spree for the path around a polygonal exclusion fence. The vehicle seemed to attempt to go around the fence in one direction, but then reverse and try the other direction, but then reverse, and repeat over and over until I switched to Acro and drove it around the edge of the fence. This happened on 3 or 4 different approaches, but not every time. I was going to share a screen shot of the path it drew but Mission Planner failed to capture a .tlog of this mission. The map view in the DataFlash Log Viewer shows where it was hunting:

    Here is a video of the real thing happening: The mission and Exclusion Fence were like this:
    Note that the mower got stuck in the blue-circled area, trying to get to a waypoint over in the red-circled area. I will research this behavior more sometime. I may be able to solve this with parameter changes, so NO COMPLAINTS on this one, just an observation! :blush:

Thanks again, dev team for this nice new feature.

Great writeup, Kenny, and I do think there may be room for improvement regarding BR behavior. I know you have some very conservative nav settings for the moment, which may be exacerbating the perceived problem, though.

My own nav settings are aggressive almost to a fault, and the primary reason was to solve exactly this problem. If you can tighten the tuning enough to stomach a very low NAVL1_PERIOD, the rover will make a pretty aggressive bid back to the desired course line after the object avoidance routine.

I’ll save some of my tuning opinions for another time and place, because I do think there’s good reason to get aggressive on the NAVL1 settings, but I don’t think it should be a requirement to get the desired behavior here.

Also, perhaps the dev team can correct me if I’m wrong, but WP_OVERSHOOT may have an effect here as well. If I understand correctly, not only is WP_RADIUS is the desired “lane” width of the intended course. In other words, a tighter WP_OVERSHOOT would also impact the amount of bias toward the depicted yellow line.

1 Like

Hi @ktrussell, your findings are very interesting to me since I have been working towards making BendyRuler better since the past year or so.
BendyRuler is a Ray based algorithm, which basically means that it does not guarantee the shortest path. The way it works is that, it just projects the location of the vehicle a few meters ahead of itself, and sees if there is a obstacle. If there is an obstacle, it shifts the target position a little bit to the left/right and sees if that’s a clear path. If it is, then it goes in that direction. Therefore with this algorithm it’s very tough to maintain the shortest possible deviation from the main WP line. Infact, even the behaviour of it returning to the previous WP line can be dangerous (and in Master we have a parameter, which when enabled will reset the Wp origin to the current position once the obstacle is cleared, so that we don’t go back to the original WP line, but continue towards the destination from where ever the Rover is currently).

What you are instead looking for is Dijkstra’s (OA_TYPE = 2). Dijkstra’s is a graph based algorithm that would plan a guaranteed shortest path between the WP’s if an obstacle is present in between, so that’s probably what you are looking for.

Note that proximity avoidance won’t work with Dijsktras because we simply do not have the computational power on board FC’s to do that. So last year we included OA_TYPE = 3, which does Dijkstra’s for the fences and BendyRuler for the proximity avoidance all together and you don’t have to compromise.

As for the BendyRuler turning back and forth near a fence, this was a HUGE problem in Rover/Copter 4.0. We have reduced the problem quiet a bit by adding this param called: “OA_BR_CONT_RATIO” … if you increase that parameter by a little bit more, you’ll find that the Rover’s tendency to turn around and look for a new path will reduce significantly… (here is a demonstration:

1 Like

Thank you, @rishabsingh3003, for a nice explanation. I have tried Dijkstra’s. Dijkstra’s seems to detect from way back, even at the originating WP, that there is an obstacle ahead and heads around it. I did not spend much time on it, but will look at it more. @Yuri_Rage posted about it here Yuri’s 4.1.0-beta Update (GPS yaw - now beta3) - ArduRover / Rover 4.1 - ArduPilot Discourse as well.

I will look more in detail and post additional information.

Early in my experimentation with BendyRuler, I changed the OA_BR_CONT_RATIO and OA_BR_CONT_ANGLE separately to understand their effect and I saw no change, if I remember, but that was before I ran into the problem with the back and forth hunting behavior. I will certainly experiment with OA_BR_CONT_RATIO as you suggest.

Thanks, Yuri. I completely agree that the more aggressive one can make the NAV tuning, the better, for many reasons. From what I (and I think you) have seen, to achieve aggressive NAV requires good mechanical tolerances (no play in linkages), and excellent steering rate tuning. I have improved mine a lot, but still have a way to go.

@ktrussell you are right. Dijkstra pre calculates the entire path even before the mission starts. What you ultimately want to achieve is hence a problem within Dijsktras and not BendyRuler, because BendyRuler simply does not care about the “larger picture”. It just sees what’s in front of it, and turns left or right to dodge it. Whereas Dijkstra’s is smart and looks at all the known obstacles before doing anything.
The right thing to do would be to enhance Dijkstra’s and provide some sort of param so that it gives an option to deviate as little as possible from the main path. That’s something that is possible.

Currently, it does what it’s supposed to, calculate the shortest path to the destination avoiding obstacles :slight_smile:

I think both (or all 3 with the blended version) of the algorithms do very useful things as they are. I can see a new algorithm for what I would like to do, or maybe it is just a change to the existing ones, with additional parameters to modify their behavior.

It may not be a good approach, but BendyRuler does such a nice job of navigation tightly around a fence, that if it just “thought” it was navigating all the way to the opposite side of the fence before releasing the controller back to its normal target of the next WP, it would work awesomely. That is what I attempted to describe in my point #3.

EDIT: If I have time, I am going to play around with the BendyRuler code. It looks very well written. I doubt I will come up with anything “pull-request” worthy, but I might have fun and make some progress.

Rishab, while you were typing your reply, perhaps I was wasting a bit of time making this visual depiction. The use case here is automated lawn mowing, where shortest path isn’t exactly important. Rather, we want to follow the desired course lines with as little deviation as possible.

The top path shows the desired outcome with as little unmowed area (orange dots) as possible, where the bottom path is the shortest one with a long, narrow unmowed area. The desired behavior seems very “BendyRuler” in nature, but like you suggest, perhaps some additional Djikstra parameters could help reduce the unmowed portion.

1 Like

@Yuri_Rage I understand. This is something that can probably be done by Dijkstra’s with some more logic. BendyRuler being a local planner, there won’t ever be any guarantee that it follows the path you want it to follow

Servers by jDrones