Rover S-Curves alpha testing

Hi @Yuri_Rage,

Thanks very much for the testing and feedback including the video.

I guess maybe the issue with the pivot turns is that it is not actually using the pivot turn controller but is instead falling back to the position controller. Maybe when your servo is replaced you could try adding a delay to the waypoint commands? The “delay” is the first field in the command.

Some warnings and known issues
Skid-steering vehicles will not pivot at a corner unless the waypoint command’s “delay” field (the first field) is set to 1 (or higher). I suspect I should change this behaviour so it is like master and pivots at any corner where the angle is at least WP_PIVOT_ANGLE.

I thought this might be confusing/annoying to have to add the “delay” but I also thought it might be interesting to see how the position controller did without the use of the pivot controller. I think we can safely assume the answer is, “not well” so I’ll modify the branch so that it always checks the angle of the next corner and uses the pivot controller if it is > WP_PIVOT_ANGLE.

Re the other two issues with SERVO_GPIO_MASK and disappearing missions, I’ll have a play and see if i can reproduce these. I suspect the SERVO_GPIO_MASK issue has been fixed in master and I’ll just need to rebase this PR.

Thanks again.

1 Like

Thanks for the reply, Randy! I did have WP_PIVOT_DELAY=1, but I did not have each waypoint delay set as you suggest. Will do that next!

I’d also suggest that “not well” is more like “not bad,” but not quite up to expectation :slight_smile:

I feel like I was really making progress before the servo fried. The tuning is quite different from previous, and I was just starting to figure it out when disaster struck. I REALLY like the oscillation recovery after the pivot that induced it, and I think a better tune will leverage the new controller well!

And a late edit - I wanted to send you a .bin log for the better tuned results, but my session was cut short. The only log I have is probably several hours of power-on time, long periods of inactivity, multiple restarts, and a few promising results sprinkled in. I’ll get some good data soon!

1 Like

This is awesome to see. Everything I see above looks great except I was concerned about the pivot turns, since that is something that is working super well, in my opinion, with the current pivot controller. SCurves with the old pivot controller is looking promising. I will try to get my vehicle out and give this a try as well, but I can’t expect that I will add anything to Yuri’s analysis since our vehicles are so similar. But I would like to join in the fun!


I’ve updated the binaries linked in the description at the top to a new 21-Dec-2021 version of the SCurves feature. The changes vs the 14-Dec-2021 version are:

  • Vehicle always pivots at corners with angle > WP_PIVOT_ANGLE (no need to set each waypoint’s “delay” field)
  • Rebased on master (should fix the SERVOx_FUNCTION=-1 hang issue)
1 Like

What is the preferred/intended method to define GPIO pins? Should I be using the SERVO_GPIO_MASK or individual SERVOx_FUNCTION params?

On one hand, the bitmask is convenient, but on the other, the servo function params are a bit easier to read and maintain. Is there a plan to deprecate one of them?


After a quick discussion with @tridge we think setting the SERVOx_FUNCTION parameter is the easiest and most intuitive way to set the pin to be a GPIO. The SERVO_GPIO_MASK will also work just as well but we think this is more for those unusual cases where the user has the servo on CAN or SBUS and then also wants to use the physical Servo pin on the autopilot as a GPIO.

1 Like


Another thing that occurred to me as I walked the dog was that I set the default PSC_VEL_D term quite high (0.3). Now I see you’ve reduced it to 0.1 which is a good thing because a high D term can easily lead to overly active servo outputs which could lead to servo burn-out like you experienced. Hopefully this was not the cause of your vehicle’s servo’s burn out but it’s something testers should be craeful of.

… so to put it more simply an concretely, maybe I should reduce the default PSC_VEL_D value from 0.3 to 0.2 and/or testers should reduce this value themselves on the first test.

Agreed about PSC_VEL_D! I think it’s also prudent to watch for I term windup, though I can’t say for sure that I experienced any of that.

My methodology for manually tuning almost always includes initially zeroing the I and D terms (along with P if FF is to be used). My goal is to minimize the use of any term other than FF (or P). I wondered what drove you to use such a high D term value.

I’m also hoping to drive ATC_STR_ANG_P down from the huge value I tried last. I expect your most recent pivot controller change will allow for that.

Again, I’m not blaming the new firmware for the servo issue, though it’s within the realm of possibility. I was being lazy/foolish with my testing methodology and not watching as closely as I should have (staying warm!), and I’m sure I’ve abused that servo more than once outside the scope of this testing, anyway.

I suspect that servo was slowly moving toward failure during the latter part of my test session. I began to fight basic steering tuning in a way I had not expected before finally just spinning in circles when the left side failed entirely.

1 Like


Great. The high PSC_VEL_D term came from testing with my AION robotics rover. I found that without the high D-term it was wavering a lot even on straight sections of the path. I must say I was in a bit of a rush though so perhaps with more effort I could have found another balance of gains that would have worked as well.

1 Like

Hey guys,

I’d be interested in doing some higher speed testing with this controller at some point (60-90mph). Is there any way we could get a list of ‘test cards’ you would like to see dedicated effort on so we can step up to that goal?

I’m curious how this controller with the PSC variables enhance braking in the approach to a WP (vs the L1 controller) with our external throttle / brake / shift mixing logic.

Odd you mention the PSC_VEL_D term - we had the same issues in tradheli before everyone switch to Loiter…

Along the way we may need to help create an enhanced tuning guide with all the different steering methods considered (skid, Ackerman, anti, parallel, etc.).

1 Like

@rmackay9, I got new servos installed, tuned in acro mode, and got things running at least as well as previous (possibly better!). I didn’t do a lot of testing before it got dark, but I did install the 21 Dec binary.

Observations so far:

The waypoint mission still disappears between boot cycles.

There is a pronounced delay at each turn now, even with WP_PIVOT_DELAY=0 and all zeros in the delay parameter column for each waypoint. It’s almost as if the autopilot has to stop and “think” at each waypoint before proceeding.

However, pivots are clean and crisp, and tracking between waypoints is quite straight.

I can send a log your way if you like.

1 Like


Thanks for the offer on testing at high speeds.

I think some important tests could be:

  • does it track along the straight line between waypoints at least as well as 4.1? Repeat this test at various speeds including very slow speeds
  • compare cornering
    • does the vehicle pass no more than WP_RADIUS from the waypoint? Test at various speeds and with various maximum accelerations (ATC_ACCEL_MAX and ATC_TURN_MAX_G)
    • test corners of various angles (e.g. 45deg, 90deg, 180deg)
    • how do you feel about cutting the corner vs overshooting?


Great, thanks for the feedback.

Re the waypoint mission disappearing, I tested it on my CubeOrange and couldn’t reproduce the problem. I suspect it is either the GCS or a script that is erasing the mission. If you’re using QGC, I know it has an option to delete the mission but I don’t have many details of this feature. Maybe try testing a couple of reboots with MP? In case it’s the script could you try setting SCR_ENABLE = 0 and then try rebooting, re-uploading, re-booting etc to see if the problem persists?

Re the delay at waypoints I can imagine a few possible causes:

  1. the pivot turn is too strict in enforcing the angle target
  2. the pivot turn does not start until the vehicle has stopped (previously it would start the moment the vehicle passed through the WP_RADIUS)
  3. the SCurve jerk (change in acceleration) is too low. To avoid overloading people with parameters I’ve hard-coded the jerk to 1m/s/s/s. This will make the vehicle’s slow down before the pivot and speed up after the pivot slower than in master.

I suspect the issue is probably 3… I’ll add a jerk parameter and we can play with that to see if it helps. I might also add some debug output so we can easily see what stage of the turn the vehicle is at and where the time is going.

Txs again!


I’ve updated the links to the binaries at the top of this discussion. This new version (rover-42dev-scurves-xxx-24Dec2021.apj) includes these changes to help get to the bottom of the delays at corners:

  1. “Pivot to xxx started” and “Pivot complete” messages to help clarify where the delay in the pivot is happening (e.g. before the pivot, during the pivot or after the pivot)
  2. reduced the WP_PIVOT_DELAY default to 0 (which won’t affect you because you’ve already set it to 0)
  3. added WP_ACCEL and WP_JERK parameters to allow configuration of the SCurve accel and jerk in autonomous modes separate from manual modes. Increasing these values should reduce any delay seen before or after pivot turns.
    • if WP_ACCEL is set to zero (the default) then the ATC_ACCEL value will be used (i.e. no change in behaviour)
    • if WP_JERK is set to zero (the default) then the WP_ACCEL or ATC_ACCEL value is used for jerk (i.e. no change in behaviour from previous test version).

… I can actually imagine that even if you increase the WP_ACCEL and WP_JERK parameter values you’ll still see a delay before/after the pivot turns in which case it means the SCurves have a built in delay which I will need to discuss with @Leonardthall.


@rmackay9, thank you for the updated binary!

I am still experiencing the loss of mission waypoints between reboots, even with scripting disabled and MIS_OPTIONS=0. I always use Mission Planner for GCS software.

The “Pivot to x started” message is repeated for the duration of the pivot turn, which makes it a little difficult to decipher the message timing, so I actually rebuilt your rover-scurve5 branch with a couple of minor debug edits as follows, including a report of the pivot delay value:

bool _did_report_pivot_start = false;
void AR_PivotTurn::check_activation(float desired_heading_deg, bool force_active)
        if (!_did_report_pivot_start) {
            gcs().send_text(MAV_SEVERITY_CRITICAL, "Pivot to %d started", (int)desired_heading_deg);
            _did_report_pivot_start = true;
        gcs().send_text(MAV_SEVERITY_CRITICAL, "Pivot complete after %dms delay", (int)get_delay_duration_ms());
        _did_report_pivot_start = false;

Indeed, the reported delay value is 0 unless commanded otherwise by parameter changes.

The delay is happening BEFORE the pivot turn. I think it has to do with the determination of whether the waypoint has been reached because I also note a similar delay at the end of the mission when the mower stops - the “mission complete” message has about the same amount of delay. There is also a brief pause between most non-pivoted waypoints.

I tried increasing WP_JERK and/or WP_ACCEL using values between 1 and 5, and that made little observable difference.

I also tried WP_RADIUS values between 0 and 5 with no observable difference.

And I tried a number of throttle and steering accel, rate, and PSC_VEL* values, but none of them made any positive difference, and I returned them to roughly the same tune as I achieved via ACRO mode observations.

I spent today “playing robots” (as my family calls it) for a bit, cooking, and enjoying the holiday with family. S-Curve support for Rover almost feels like a Christmas gift. Merry Christmas, Happy Holidays, and all the best to you and the ArduPilot community!

1 Like


Thanks very much for that testing and bug fix. I’ve compiled a new version which includes an equivalent fix and also adds an “scurve finished” message when the scurves portion complete (before the pivot).

When you have a chance I’d like to get a log from you to see if you’re seeing what I’m seeing in SITL. This could be with the latest binary i’ve linked in the top discussion or just from this most recent test you’ve done.

… basically I can reproduce the delay in SITL so I should be able to get to the bottom of it.


Sounds good! I’ll try and get a test session in tomorrow before it rains this week.

You should have Google Drive access to my latest test session log from Christmas Eve.

1 Like

Hi @Yuri_Rage,

Thanks for that. I can’t immediately find the link to this latest log (I’ve got one for the previous log).

In any case, this delay at the waypoint is caused by a slight overshoot in the speed controller while stopping (it stops too quickly) which has the knock-on effect of causing the SCurve “time scaling” code to slow the SCurves progress. FYI this “time scaling” code is there to deal with situations where the vehicle can’t keep up with the pre-calculated path. It basically slows down the path so the vehicle can catch-up.

If you could reduce CRUISE_THROTTLE from “55” to “50” or maybe even “45” that might reduce the overshoot and the problem might go away.

… in the meantime Leonard suggests we should turn off the time scaling during the braking phase so I will come up with a new version soon which does that.

Txs again for your help with this.

Well, it just got dark, but as luck would have it, I want to test the new SIYI camera in low light (update - it worked fairly well with some supplemental lighting). I will load your latest binary with the message fixes, reduce the throttle setting, and send a log your way shortly.

@rmackay9, I just uploaded a 20211230 .bin log to a Google Drive folder and gave you complete access to that folder using your Yahoo email address.

I don’t think the lower CRUISE_THROTTLE setting made much difference.

1 Like