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.
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:
- the pivot turn is too strict in enforcing the angle target
- the pivot turn does not start until the vehicle has stopped (previously it would start the moment the vehicle passed through the WP_RADIUS)
- 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:
- “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)
- reduced the WP_PIVOT_DELAY default to 0 (which won’t affect you because you’ve already set it to 0)
- 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.
2 Likes
@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!
2 Likes
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.
2 Likes
Sounds good! I’ll try and get a test session in tomorrow before it rains this week.
EDIT:
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
Just spotted this topic now, brilliant stuff.
Please note that at 55 years of age I have ZERO dev skills, and very likely will never change that. However, I am firstly a boat skipper and secondly a cartographer. On these two things I have many years of experience and am more than happy to share where I can.
When I started using autonomous craft for collecting sonar data in late 2015 one of the single biggest struggles I ran into was ‘Wobbly Path between Waypoints’.
Lesson 1 - Throttle
In 2019 I accidentally got my boat to go straight from waypoint to waypoint when the throttle lever came loose and the craft maintained a 100% steady throttle which resulted in my very first perfect grid. The lesson learned here is that it was the varying throttle that was the culprit.
Lesson 2 - Size & Weight of Craft
Just when I thought I had solved my problems, each boat was different. To date I cannot get the same navigation performance on my other craft even if it is identical in size and shape, but just heavier. The lesson here is don’t expect an ‘oil tanker’ to turn like a ‘speed boat’.
Lesson 3 - Turning Capability
No two craft are identical, even if they look the same. This will effect your navigation performance profoundly. Even a full fuel tank at the start of the day compared to empty at the end of the day is going to make a difference to the turning capability. So first step for any craft before doing anything is to determine the Turning Capability to both port and starboard if you using an outboard type motor due to the torque of the prop in the water. Weather and current conditions can also influence this in a big way.
Here is what I get on my 4m AIMy -
Lesson 4 - Heading Angles WPT to WPT
As long as there are no parameters ‘fiddling’ with the throttle or steering in Auto, we know that my 4m AIMy for example can 100% make a turn with a radius of 8,5m to both port and starboard weather permitting.
Therefore if she were to start a turn 8,5m from the waypoint on a right angled turn she would exit perfectly on the track to the next waypoint and there would be no need for overshoot or oversteer.
Should the angle be acute, then at a 60° angle for example she would need to start turning around 12m before the waypoint.
2 Likes
I think this evolution will help you quite a bit. The tuning is more straightforward, and the position controller does a nice job of nailing the course and heading with less fiddling overall. There are some kinks to work out, and I’m eternally grateful to Randy, Dr Hall, and the entire dev team for their efforts. Happy New Year!
2 Likes
Yuri I agree 100% on both the subject as well as those making it all happen.
I’ve update the binaries linked from the top description with the following changes:
- SCurve time scaling disabled during braking period before stopping at a waypoint (this should reduce the delay @Yuri_Rage has been seeing before pivot turns). Also added WPDT debug log message so we can more easily see what’s going on.
- Stop or loiter at waypoints which have a delay (previously the position controller remained active during the delay which could cause the vehicle to rock back and forth)
- Guided mode and BendyRuler may pivot if required
- Guided mode reports when it has reached destination
- Internal Errors added if invalid destinations received in Auto, Guide, RTL, etc (should never happen)
- Rebased on master
- CRUISE_SPEED and CRUISE_THROTTLE are used to set the ATC_SPEED_FF value (this should not affect performance but does allow us to see the speed controller’s feed forward output in the logs)
All feedback is greatly appreciated!
2 Likes
Well, I can report that the changes are significant! But…not as impactful as I had hoped.
As you may recall, I had previously increased the ATC_STR_ANG_P and ATC_STR_RAT_FF parameters to be significantly more aggressive than under L1 control. With this latest revision, I had to dial those back closer to their previous settings, lest the mower wildly overshoot. So, something has changed!
I also tried enabling one fence and BendyRuler avoidance. I think that was too much to ask given the state of the tune. I don’t think I trust things enough to enable that again under this revision. If we can get things behaving a little more predictably, I can (and will) try that again.
However, I’m still seeing delays as bad or even worse than previous. I have a few things to do before testing further, but I will grab a log from a clean boot cycle later this evening.
AND - I just can’t seem to figure out how to keep from wiping the waypoints out between reboots. With scripting disabled and all parameters set to oppose deleting waypoints, they still disappear after rebooting the autopilot.
@rmackay9, log uploaded to the same Google Drive folder I’ve been using. Upon review of the log, there are quite a few steering and throttle overshoots, so I may still have the controller inputs a little too aggressively tuned, but I hope the log is of value, nonetheless.
1 Like