I intend to test this on the mower before the week’s end. Sorry for the delay!
1 Like
I did another round of testing today. WP_Speed was 4m/s. ATC_ACCEL_MAX and ATC_DECEL_MAX were both 2m/s. Also reduced TURN_MAX_G to 0.4 (was previously 2!)
Wasn’t able to lengthen the short legs, due to a few obstacles on the ground.
The graphed results do show the slowdowns, albeit much reduced on the WP1-2 corners.
I’m unsure about the large difference in slowdowns between the 2 pairs of corners. WP1-2 are 18m apart and WP 3-4 are 14m apart. It does seem like the slowdowns are very sensitive to how far apart the waypoints are.
Txs again for testing. So I think you’ve bumped into the limitation of Leonard’s most recent improvement. Although it may now cut the corner to maintain speed, it can only do this if it has gotten up to full speed before reaching the corner.
I’ve discussed this with Leonard and he’s described it like this:
On a short leg (like shown below) a human driver might just keep the steering wheel turned to the left constantly as he/she rounds wp1 and wp2 (e.g. never return the steering wheel to the center) but SCurves don’t do this. SCurves plans the corners so there is always a short moment where the steering wheel is centered. If it can’t do this then it slows down before the corner.
I don’t think we can improve this immediately at least so I guess we need to decide if this is a blocker or not.
1 Like
Yep, that agrees with the plot of my steering during the run. The vehicle always wants to return to 0 turnrate/lat_accel between waypoints:
At this point I see this as more of a tuning issue, not a bug or blocker. With the correct combination of speed and max turnrate/lat_accel, the effect should be reduced.
I foresee this as a common support question when s-curves makes it to stable, so having something in the documentation explaining the effect and how to reduce it would be useful.
2 Likes
@stephendade are you being a bit conservative witrh your longitudinal and lateral acceleration limits? I would have thought most RC cars could handle higher. It would be interesting to see if that stops the slowdown. Noting you might have to also expand your WP radius.
Most likely!
With the following limits:
TURN_MAX_G 3
ATC_ACCEL_MAX 20
ATC_DECEL_MAX 20
I managed to completely eliminate the slowdowns at 4 m/s cruise speed.
At 5 m/s cruise, I was getting some slight slowdowns to 4 m/s. The rover was starting to slip during turns, so I’ve probably reached the limit of what the vehicle can do (at least with my short box course)
As long as I keep any big turns at least 18m apart, I shouldn’t see any slowdowns.
I’m pretty happy now 
1 Like
Another round of testing today.
This test was to check the effect of speed on the tuning and path. For example, could I tune at a lower speed and then run the mission at a higher speed?
The Tuning:
I tuned at 3m/s. I started by raising PSC_VEL_P until the corners tracked nicely. I did see a little oscillation on the straights, so I reduced PSC_VEL_P a little until it was smoothed out. Then I finished with increasing PSC_VEL_D just to make the corners a little more responsive, taking case not to induce oscillations in the straights.
Final params were:
PSC_POS_P 0.200000
PSC_VEL_D 0.350000
PSC_VEL_FF 0.000000
PSC_VEL_FLTD 5.000000
PSC_VEL_FLTE 5.000000
PSC_VEL_I 0.200000
PSC_VEL_IMAX 1.000000
PSC_VEL_P 4.500000
In terms of consistency, I got up to 30cm variation between tracks, though usually it was <20cm. This was with a HERE3 GPS (no RTK).
Increasing the speed
I then used this tune at 4m/s and 5m/s speeds.
On the corners I got up to 1.4m variation (compared to 3m/s track), and up to 1m variation on the straights.
Taking a closer look at the corners at these 3 speeds (3, 4 and 5m/s):
The vehicle cut the corner more shallowly (started turning sooner) at higher speeds.
From this, it does confirm that an S-curve tune does hold at varying cruise speeds on a vehicle, noting that the vehicle may cut the corners a little more shallowly at higher speeds, up until it hits the lateral acceleration limits.
1 Like
Thanks very much for this and the details on the position control tuning params that you found worked.
So the POS_P, VEL_I (and filters) stayed at the defaults but you really increased the VEL_P (4x the default of 1.0) and VEL_D (normally zero, changed to 0.35). On my AION robotics rover a high D also worked (but didn’t help much) but on Yuri’s (I think) this led to oscillation.
I think before 4.3 is released (which is still 6 months away) it is important that we get the position controller defaults set so that they work on a wide variety of vehicles and also that we clarify the procedure users should use to tune the position controller… sounds like your method is a good starting point.
Also good to hear that the tune worked at various speeds.
I think I might merge scurves to master today… it’s a huge change and I worry a bit about the disruption to existing users but hopefully we can work out those issues in the coming months ahead of the 4.3 release.
Sounds very promising - will S curves be an option, or will it be a hard switch from L1 to S curves?
I’m assuming you’ll let us know once it’s in?
It is a hard switch from L1 to SCurves and I’ve already merged it to master (aka “latest”, aka “DEV”). It will stay in latest now along with all the other latest developments until we begin beta testing of Rover-4.3.0 which is about 6 months from now. Until then it can still be loaded from Mission Planner’s Install Firmware screen by pressing Ctrl-Q.
1 Like
So all the functionality you had in the pre-build Binaries in post 1 are now in Master?
1 Like
Can confirm that SCurves for Rover have been merged to the current master branch (4.3 at present). I assume that all testing from here forward should probably be via the latest build binaries rather than the alpha versions above (unless @rmackay9 needs further testing outside the master branch).
I’ll be loading the latest Cube Orange binary this afternoon for a long overdue test/tune session while doing some actual mowing…as long as the mower starts!
For those who haven’t tried it before, it can be highly productive to tune during a live auto mission - most tuning parameters are updated in real time without rebooting or even restarting the mission. Just be sure to have some wide open space and proper failsafes/emergency stops in place! Occasionally, tuning this way can induce some strange behavior, so if the results are wildly different than expectation, try rebooting before continuing (steps to reproduce are difficult to discern…and I know I’m recommending a potentially risky practice, so probably not worth tracking).
1 Like
Excellent test and tune session today! I uploaded a log file to the Google drive location shared with your Yahoo email address.
All testing was done with the current master branch, which should be the binary located here.
I first went back to basics, tuning steering and throttle as best I could, since I was trying some really unconventional values during my last session with the mower (from a month ago or more…mostly curiously playing with basic tuning vs the position controller…it was a terrible tune that needed fixing!). I then moved on to ATC_STR_ANG_P for pivot turns, and finally, tuning the position controller.
I made a couple of minor tuning parameter changes during the first few waypoints of the logged auto mission - hopefully those changes show up in the log. Otherwise, the final parameters are attached below.
All obstacle avoidance and fence parameters were disabled for the duration.
This very zoomed screenshot shows nicely cut corners and a bit of crosstrack error and oscillation that I’m hoping is further tunable. Log review shows worst case crosstrack error of 34cm, but mostly remaining within 20cm, which is near acceptable for my use case, but I’d like to see half that or less.
And here’s a picture of multiple pivot turns with slightly more error than the longer legs and non-pivoted turns:
(it was a very inefficient mowing pattern that increased the amount of time I had to test/tune)
Observations:
-
A good initial tune is a MUST! I know this should likely go without saying, but it looks like the position controller is particularly sensitive to poor steering and throttle tuning, where NAVL1 could sometimes mask tuning errors.
-
Pivot turn behavior is much improved since my last session. Delays are still present at times, but generally acceptable, and possibly more avoidable with better acceleration tuning (I did not do much of that today, focusing mainly on steering, throttle, basic pivot turns, and PSC* values).
-
There’s some very interesting interplay between ATC_STR_ANG_P and the position controller. If ATC_STR_ANG_P is set even slightly too low, there is a lot of hesitation when the position controller picks up the task of navigating to the next waypoint. A slight pivot overshoot seems far preferable to any undershoot, although a slight undershoot generally results in better path alignment after a sometimes lengthy delay. A slight overshoot tends to result in little to no delay after a pivot turn.
-
Setting ANY PSC* value too high can result in very undesirable behavior - nasty oscillations/stuttering, particularly exiting pivot turns. In particular, I did not like anything I saw with a PSC_VEL_D value over 0.05.
-
Because I didn’t do much acceleration value tuning, I probably can’t complain much about the somewhat frequent slowing at non-pivoted waypoints. It seemed generally acceptable, but there is some efficiency to be gained there, probably via tuning.
-
I did have a go at clamping the I term using PSC_VEL_IMAX, but I didn’t see much difference between 0 and 1 values, so left it at 1 for the remainder of the session. Graphing the I term with the PID tuning mask set to the position controller didn’t show any obvious buildup, though I have not yet reviewed the pertinent log entries to confirm that.
1 Like
This are an enviable results and give me something to look forward to this summer.
1 Like
I am just about finished with building a new boat just for this as all my other boats are out on projects this year.
What do I need in order to test this on a Pixhawk 4 - Pixhawk 4 – Holybro
Hi @John_Easton,
We have merged this feature to master (aka “latest”) so it can be installed using MP’s Firmware Install screen but just push “Ctrl-Q” and hopefully the label below the Rover icon will change to “Rover V4.3.0-dev DEV”.
It should just work although some navigation parameters have changed. For example the NAVL1_ parameters are all gone. There are some new PSC_xxx parameter that may require tuning for your vehicle… but hopefully the out-of-the-box experience will be OK.
1 Like
That is awesome Randy, I am so excited to test this.
1 Like
In the version from the title (March 5th), the reverse problem in blheli has been fixed?
1 Like
Probably not, you need the version 4.2.0-rc1 from yesterday for that.
1 Like
Grab the latest 4.3-dev master from the nightly builds. That should contain SCurve navigation and all 4.1/4.2-series fixes (unless that very recent fix hasn’t been merged yet).
2 Likes