Took a while to figure out why changing TURN_RADIUS was having no effect in AUTO. Seems it is limited by WP_RADIUS. Why? The WP_RADIUS sets how close to get before its considered ‘arrived’.
I would still like a small WP_RADIUS (0.5mts) but need a large turn radius (5 mts) so my vehicle does not collide with its trailer.
Any suggestions please?
Maybe instead you can work around with WP_PIVOT_RATE for your use case
I think that only governs the rate of a pivot turn on skid-steer. I have disabled pivot turns as turning ‘on the spot’ will not work with a trailer.
You have conflicting goals. The 4.3+ nav controller will attempt to cut the corner and align the vehicle with the next leg whilst honoring velocity, accel, rate, and radius parameters. Setting a large turn radius will indeed result in more corner cutting, but I think waypoint radius takes priority, forcing the vehicle to always pass within that radius, which, when mismatched with the other params, will cause an overshoot on the backside of the turn and potentially abrupt course correction.
@rmackay9, I’ve noticed that it can be finicky to set WP_RADIUS correctly as a result, and (slightly off topic) I’m wondering also if WP_RADIUS is now essentially ignored for pivoted turns. I think SCurve nav could nearly do without the WP_RADIUS param, if I understand some of the underpinnings correctly.
1 Like
You’re experiencing some of the mysteries of the system. I’ve been mowing, with MP, closing on a year now. Some of the parameters still baffle me, to the point that sometimes I feel it’s a crap shoot about what a change will do.
I do use Pivot turns. WP_RADIUS is a tool I use to slow the rover as it approaches the turn. The title of the parameter seems to suggest that it would set a turn radius, but it doesn’t seem so.
A friend and mentor uses his rover to pull a trailer. Let’s see if I can get him to chime in here.
Bill
Thanks Bill, yep some things are a bit baffling. I dont see why having a small WP rad should conflict with a large Turn rad. I dont want the turn to start much before the WP but dont care if the turn is very large once it starts. It may take a short distance to reestablish on the grid but thats fine. Perhaps I could overcome having a large WP radius by setting an overrun (polygon auto grid).
Anyway like the heading suggests it seems turn radius will not go larger than the WP radius (annoyingly). Pivot turns, apart from colliding with a trailer, also chew up the lawn on a 4 wheel skid steer.
The long term aim is to drag a metal detector trailer.
S Curve path planning cuts the corners to produce smooth transitions from one leg to the next. With a large turn radius, you are asking for a larger cut corner. With a small waypoint radius, you are asking for the opposite. It would seem the latter is prioritized based on the behavior you’re seeing.
2 Likes
Hey Vince - I’m the guy Bill was referring to about pulling trailers. I am NOT running 4.3 (S-curves) but 4.2.2 (with no pivot turns) with our tug alternating between pulling a 60" trial mower and a 10’ weed wiper. Have about 300 hrs total to date between the two.
For my application, I found the following parameters useful in keeping the rig from getting hung up.
- WP-RADIUS - 2.0m. (minimum)
- WP-OVERSHOOT- 1.0M
- ATC-STR-RATE-MAX - 40 Deg/Sec
- ATC-TURN-MAX-G - 0.12g
I’m sure these settings are not the most elegant solutions, but they work with the trailer geometry we have. Will be happy to post the full parameter list if it might be helpful.
Couple of other things you might consider. I use spiral patterns and make sure the missions don’t have any WP turns more than ~120 degrees. Less turning angle is safer and reduces the chance of getting the rig in a bind. Also I don’t get real concerned on “perfect” turns at WPs. Turning “consistency” is much more important. If the trailer “misses” a bit of an arc at a WP but makes the same type of turn the next time around, the area “missed” by the first pass will likely be caught during the second. If it’s still a problem, increasing the overlap will help. Good luck!
2 Likes
This may be slightly related, but it is not the root cause of the behavior you’re seeing:
AR_WPNav: Rover 4.3+ does not honor WP_RADIUS · Issue #23457 · ArduPilot/ardupilot (github.com)
Still, for an S Curve path (a cut corner), the logic uses the larger of WP_RADIUS or TURN_RADIUS, which is about the only way to make those values make sense, if we are to keep them both in the parameter set.
Steve’s and Bill’s replies above apply only to 4.2 and previous (except for the generic advice about path planning for trailers). Your conundrum is unique to 4.3+ firmware. I suppose if you want to allow a path overshoot, you could try and coerce the devs to include a parameter to prioritize waypoint radius over turn radius, but I think you’ll meet resistance there.
I think the solution for your vehicle is to either start your turns later (place the waypoint farther downrange) or include an extra waypoint beyond the critical one such that the corner is not cut so much.
1 Like
I replied on facebook but it’s actually better to have the discussion here.
I see that Yuri has already said what I wanted to say which is that with Rover-4.3.0-beta the navigation uses S-Curves to plan the path which is the same as what Copter uses. This means the vehicle cuts the corners instead of overshooting like it did in 4.2.
As a bit of background, because ackermann steering vehicles can’t accelerate instantly in any direction (like skid-steering vehicles and Copters), when faced with a sharp corner the navigation needs to either overshoot or cut the corner. Either method is valid choice of course and either can achieve similar paths but it affects where the waypoints are placed.
By the way, you can actually cause Rover-4.3 to overshoot instead of cut the corner by adding a delay at the waypoint (e.g. set the WP command’s “Delay” field to 1). This will lead to the vehicle slowing down at the waypoint but it probably won’t come to a complete stop. The turn after the corner could be slightly aggressive though.
I actually do like the idea of adding support for both cut-the-corner and overshoot behaviours. It’s a bit tricky but it would be nice to have.
1 Like