It’s running to the limit of TURN_MAX_G, but still overshoots sharp corners as well as slowing for the corner. However, it’s either turning too late, or not slowing enough.
Increasing the ACCEL and DECEL MAX doesn’t seem to affect much, but maybe reduces the slowing slightly (at the cost of more overshoot).
Bringing WP_ACCEL to 1 (or seemingly changing any of the other params to 1) gives much smoother nav, but still slows a lot for the sharp corner.
I’ve tried bumping up the WP_RADIUS and the ATC_DECEL_MAX, and they help a little on making corners faster, but it still slows. It’s not getting close to TURN_MAX_G, so theoretically should be able to turn faster.
@rmackay9, huge improvements here! Using 12Jan2022b, there were few to no delays at any waypoints, and things went fairly smoothly once I got the tuning sorted a bit (and there’s probably some more improvement to be had in my tuning).
Pivot turns were nicely controlled with no undue delay, and course control between pivoted waypoints was generally very good.
Where I encountered the most difficulty was in smoothing a somewhat aggressive “lurch” at non-pivoted waypoints, where the steering rate would pretty rapidly increase, resulting in an overshoot of the desired course and subsequent oscillation (depicted most clearly at points 3-4 and 6-7 in the image below).
I tried various values for PSC_POS_P and PSC_VEL_P ranging from 0.1 to 0.5, finally settling on 0.4 for each as the best I could manage. Reducing the P terms really just made the correction take longer rather than reducing the magnitude of the overshoot as I’d hoped.
I resorted to trying to limit the steering “aggression” by reducing ATC_TURN_MAX_G, ATC_STR_ACC_MAX, ATC_STR_RAT_MAX, and finally ATC_STR_RAT_SMAX and ATC_STR_RAT_FF. I did achieve a little bit better result when I pinned ATC_STR_RAT_SMAX to its lower limit of 10, but nothing eliminated the lurch/overshoot behavior at non-pivoted waypoints even when the value reductions made pivot turns painfully slow.
I do still have MOT_STR_THR_MIX set to its max of 1.0 - maybe that should be reduced?
A review of the log (rather than just eyeballing the real-time tuning graph) shows frequent/consistent overshoots of the desired rate. Maybe it’s as simple as reducing the steering rate FF term (and possibly using a non-zero P value).
Txs as always for testing. I’m very relieved that the delays at pivot waypoints is gone because that issue has been hanging around for a while. I might try removing the change I made earlier which froze “spline time” during segment’s slow-down phase because it seems that wasn’t the core problem… maybe I’ll give you a special firmware that allows turning that on/off so we can be sure we don’t take a step backwards.
For “non-pivoted lurch” hopefully we can determine if it’s a lower level control issue or an SCurve path shape issue. I’m not sure if MOT_STR_THR_MIX will have much impact… it’s possible but I suspect 1.0 is fine.
After reviewing the log, I’d like to try reducing ATC_STR_RAT_FF from 0.3 to 0.2 and then increasing the P term to 0.1 or more. I think FF is blindly too aggressive, and a little proportional feedback might be all that’s needed. I will let you know how that goes.
The SCurve path is created using a max acceleration which is the minimum of ATC_ACCEL_MAX, ATC_DECEL_MAX, ATC_TURN_MAX_G*9.81 and WP_ACCEL. It’s done this way because the SCurves path planner can only accept a single acceleration so to be sure that we don’t ask the vehicle to do anything it is not physically capable of we need to use the minimum.
In general setting any of these accelerations to a low value will cause the short-cut at the corners to be larger but the maximum distance from the waypoint at the corner will never be larger than WP_RADIUS so sometimes it will need to reduce the speed into the corner to keep the acceleration below the limit and within WP_RADIUS. … so to avoid the vehicle slowing down set all accelerations to be low and WP_RADIUS to be large.
When it comes to the vehicle not staying on the path, this will be caused by the limitations of the vehicle or the tuning of the position controller. Note that the simulated vehicle’s limitations that are not changed with the parameters mentioned so far. E.g. increasing ATC_ACCEL_MAX does not change the underlying physical limitations of the simulated vehicle… it just changes what the attitude controller will try to get the vehicle to do. I think the simulated Ackermann steering rover’s maximum acceleration is about 1m/s/s.
@rmackay9, Just reporting that I loaded the latest alpha today finally. I only had about 30 minutes to test before dark, but I only had to change one PSC_ parameter to get a decent 1st AUTO run. The change was to set PSC_VEL_D to 0.
I did have a little delay during pivot turns, but it was minor and I may be able to change the pivot rate or other parameters and overcome it. (I had OA_TYPE=0, by the way.)
At this point, I have nothing to contribute to the cause, but wanted you to know I am at least on the bandwagon!
I was correct about my steering FF term being the cause of the “lurches” at waypoints. I re-tuned the steering and eliminated the rate overshoots. Things are behaving much better now.
I’m having a little trouble avoiding an overshoot of non -pivoted waypoints. It’s minor, but the path never cuts inside the turn as expected but rather overshoots and comes back. I’ve tried altering the accel, max-G, and radius values all over the place, and I can never get rid of that overshoot.
Just checking this is a typo in the post and not in the code - TURN_MAX_G should be multiplied by 9.81, not divided in order to get an acceleration in m/s/s like ATC_ACCEL etc.
Can you point me to the section where the code decides that strong text now is the time to initiate the turn?
Yes, that was a typo. It should be ATC_TURN_MAX_G multiplied by 9.81. I’ve fixed it above txs.
The way SCurves cause the vehicle to turn is the current leg’s scurve’s output and the next leg’s scurve’s output are added together. So the turn starts when the current leg enters it’s braking stage. The exact code is (I think) here in SCurve::advance_target_along_track().
I’ve updated the binaries at the top of the discussion with just one improvement:
WP_OPTIONS added (temporarily) to allow testing the SCurve slow down behaviour
0 = “normal” behaviour (e.g. scurve time scaling is always enabled)
1 = scurve time scaling disabled during slow down
While investigating the delay-during-pivot-turns issue we added this special behaviour to disable “scurve time scaling” as the vehicle slows down to stop at a waypoint. Later on we found out that the biggest cause of the problem was actually the “SCurve Jerk time” setting was too low. So basically I want to remove the special behaviour if it’s not useful.
@Yuri_Rage no pressure of course but if you have a chance to test pivot turns with this parameter set at 0 and 1 that would be great. I don’t think you’ll notice difference but let’s see!
This branch has also been rebased on master.
UPDATE: I tested on my AION robotics rover:
I couldn’t consistently see any difference in behaviour between WP_OPTIONS=0 vs 1
changing PSC_VEL_D to 0, 0.1 or 0.3 didn’t make much difference to straight line performance
I don’t have an RTK GPS on my vehicle though so the vehicle’s performance is quite variable. Sometimes it seems rock solid as it travels in a straight line between waypoints and other times it wavers on the path. I guess I need a better GPS so I can more easily distinguish between what is an estimation issue and what is a control issue.
I think I’m seeing part of my problem (or at least something I’m missing) - in order to fully diagnose things, I need to look at desired vs achieved turn rate as well as desired N and E velocities, ideally with a square course. There’s a combination of what the system WANTS the vehicle to do, versus what the vehicle can achieve. My problems may be a result of perfect planning but poor execution.
May be time for an improvement request to implement GCS_PID_MASK1 / GCS_PID_MASK2 so you can look at two things at once.
The “perfect planning but poor execution” comment is a good one. Users often complain of the vehicle performing poorly in auto mode and spend time trying to tune the navigation related parameters but the real problem is down in the lower level lower level speed and turn-rate controllers.
Re GCS_PID_MASK, the vehicle code actually can send the PID outputs for all the PID objects without any troubles. The issue is the the ground stations are not able to display them separately.
I have not forgotten about this test - been a bit busy with all sorts of things amongst some uncooperative weather. I will try and get this loaded and tested soon!
The weather has improved, so testing should be easy this week.
Caught the mention in the Dev Call about waypoint disappearance. I have experienced it in 4.2 master (and alpha releases alike) on the mower but not on my other little RC truck Rover. I still suspect a hardware oddity vs a bug and will try and nail it down.
1 Feb update:
@rmackay9, I finally tested your 17 Jan alpha firmware today. You’re right, I noticed no real difference between WP_OPTIONS=0 vs 1.
The mysteries I’d like to solve:
Why even with a WP_RADIUS of nearly 3m does the S-Curve planning not turn sooner? It’s overshooting the non-pivoted waypoints by a large enough margin to cause an oscillation as course is regained.
Why do waypoints disappear between reboots? Yep, it’s still present, and today I switched to a brand new SD card of higher quality (since once before I thought I correlated a full SD card to the disappearance issue, despite its likelihood being low).
Log file will be in the same place as usual - WP_OPTIONS=1 is the first lap of the auto mission, then WP_OPTIONS=0 after the brief pause in hold mode.
Re WP_OPTIONS, this is good to hear 'cuz it means (as expected) the SCurve scaling during slowdown is uneccessary. I’ll remove that 'cuz it’s unnecessary complexity.
Re the vehicle not starting the turn sooner, the issue is the SCurve path is built using the lowest of the various accelerations (ATC_ACCEL, ATC_TURN_MAX_G, WP_ACCEL) and also the desired speed (WP_SPEED). So if the accelerations are too high or the speed is too low then it will tend to be a sharp corner. The SCurves also can’t accept a minimum turn radius (yet) so the corners can be sharper than the vehicle is capable of actually turning.
I see ATC_ACCEL is set to 4 (and ATC_TURN_MAX_G is 0.4 which is roughly the same as 4m/s/s) so setting WP_ACCEL to a much lower value like 0.5 or 1 should result in more cutting of the corners during turns. Here’s a screen shot from SITL showing the difference. With WP_SPEED = 1.4 and WP_ACCEL = 4 it overshoots the corner but when WP_ACCEL = 0.5 it slightly cuts the corner.
I’ll follow up with PeterB re the mission erase. If you have a chance to test with Rover-4.1.x to see if the problem happens with the stable version this will give us some clues as to the cause but no pressure. We need to investigate further on our side as well.
Ok, will do on both the parameter/turn issue and 4.1 vs 4.2 mission erase!
Seems as if we are closing in on a beta release of the S-Curve controller. I think it’s very exciting! Not sure the community at large has realized the impact. It seems like my frustrations with it come down to tuning vs actual capability at this point!
PeterB and I discussed the mission erase problem and we suspect this is another variation of the infamous parameter reset bug that plagued us for so long. The issue may be that while we’ve added protection against parameter resets we overlooked other data that is stored in the eeprom including the mission and fences (polygon, inclusion/exclusion).
I wonder if you’ve noticed that the fences are also being erased? … or is it just the missions? If both are disappearing then it is likely this problem.
There are two well known causes of the parameter reset issue:
telemetry data flowing into the autopilot during the boot-up phase. This has been fixed by patching the bootloader. Your board may have an older bootloader on it though so upgrading it may help.
erratic voltage during power-up. The eeprom chip needs the voltage to monotonically increase… if it dips during power-up it can be corrupted.
My fences have also disappeared, but I have not tried repopulating them to see if they persist across boot cycles since OA has been a little odd with the new nav controller.
I suspect it may be the boot loader. This Cube was purchased right after the ADSB carrier board was released, and I don’t think I ever updated the boot loader.
I would be surprised if I have a power issue but will put an oscilloscope on it if a boot loader update is unsuccessful.
In simulator testing setting PSC_VEL_IMAX = 0 (and/or PSC_VEL_I = 0) improves performance in at least some cases. The issue is that the position controller works in earth-frame (North-East) but our lower level controls are in body-frame (forward-back and lateral). This can mean that forward-back I-term buildup (caused by the vehicle not being able to keep up with the WP_SPEED) can be partially or completely transferred to the lateral axis after the next corner causing the vehicle to stay off the path for a while as it works off the I-term buildup.
