Hi @mookai1973,
Thanks very much for offering to pitch in with testing. The CubeBlack also has an F4 CPU just like the Pixhawk1 so I don’t think it will be possible to get the script running on a CubeBlack either sadly
Hi @rmackay9,
Thank you so much for your reply,
Ok maybe I will try to look and order cube orange soon.
Thank you for your develop and build a great software.
Kai
1 Like
Hey Randy - can i put my hand up for Qiotek Zealot H743. Im about to have another tuning session next couple of days, will share results and observations.
I’m willing to give my rover a go. I am using a Matek H743. Will one of the prebuilt binaries listed work? If so, which one?
Thanks very much for helping with testing! I’ve linked firmwares for the QioTekZealotH743 and MatekH743 in the first post of this topic.
New more capable FC installed and the attached is a Baseline (V4.4.0-beta2) Auto Mission with the parameters this has been running on for awhile. The next step is to Update to the Dev Quicktune version, run that and see what’s changed and repeat the mission. Should be fun!
Redcat7 V4.4.0-beta2 baseline
2 Likes
Tried my hand at QuickTune on the mower this evening with mixed results.
First, a minor bug report - if you enable QuikTune by switching the RC channel to the middle position while the vehicle is in any state other than CIRCLE mode, it sends a warning message but then appears to enter the tuning routine, anyway, sending periodic messages about PID term changes that are impossible to have properly achieved.
Started with a decent tune on a CubeOrange and the 4.5-dev binary linked above.
Initial steering rate tuning seemed to work fine but got stuck on repeated instances of RTun: increase steering (x% < 10%) for many, many laps!
Accidentally skipped speed tuning, mistakenly thinking that I was skipping the failed portion of the steering tune (need to RTFM!). My manual throttle tune is quite good, though.
Proceeded to PSC tuning which finished VERY fast and slightly increased the I and D terms but greatly reduced the P term (from 0.8 to ~0.2)
Lots of oscillations, so I manually increased the P term back closer to my manual setting, and it settled down enough to try an AUTO mission.
AUTO mission had some hiccups (some 360s and stuck pivoting in circles at one point). But straight line tracking did appear slightly improved, though waypoint overshoots still present.
Parameters attached. Left batch logging enabled (from other tuning experiments) and did too much at once, so I won’t torture you with the 1GB+ log.
20230614 4.5-dev post QuikTune.param (16.4 KB)
20230614 4.5-dev pre QuikTune.param (16.3 KB)
Will try again tomorrow with a better understanding of the script and its parameters.
1 Like
Hi @Yuri_Rage,
Thanks very much for giving it a try.
The “RTUN: increase steering (x < 10%)” message is because it needs the steering to be at least 10% output in order to calculate the feedforward properly. A circle with a smaller radius should resolve this… or on a skid-steering vehicle increasing the speed would also work.
While the vehicle is in Circle mode (or Loiter-turns within Auto) the do-change-speed button should work.
1 Like
All makes sense, and thank you! I made another mistaken assumption that a larger circle would be better and only reduced the radius from the default of 20 to 15m. On to the next session!
1 Like
Script indicated success this afternoon using a smaller circle radius.
The results are quite aggressive gains that result in a nearly undriveable tune. Oscillations across the board, which are quite apparent in the log as the script progresses.
After the QuikTune, I eyeballed some quick fixes to the overly aggressive gains, and the straight line nav tracking looks pretty good, though there’s still a bit of higher frequency oscillation that might be keeping crosstrack error minimal while giving the drive servos a hefty workout.
Hi @Yuri_Rage,
Thanks very much for the log. Here are my initial thoughts:
- The script worked as expected even though it didn’t calculate good gains
- We should increase the gain margin so that we end up with a gentler tune. RTUN_GAIN_MARGIN is currently 60% (meaning final gains are 40% of the gain that causes oscillation), this should be increased to 80% or maybe even 90% which seems shockingly far from the oscillation gain.
- We should add a new RTUN_STR_FF_MARGIN which sets the FF gain lower than the “ideal” gain
Some more analysis first of the steering turn rate tuning:
Here’s a typical part from the beginning of the log showing the RTUN message “SRate” (aka “Slew Rate”, aka “oscillation”) and we see that as expected the oscillation raising as the D gain is increased. It rises and rises and then finally climbs above 5 (RTUN_OSC_MAX = 5) which is when oscillation is detected and then the gains are reduced by RTUN_GAIN_MARGIN (60%)
Below is a zoom-in of the above from the moment the oscillation is detected and the subsequent reduction of the gain to the final gain. So in this example the oscillation is detected when the ATC_STR_RAT_D gain is 0.1668 so the final gain is this number backed off by 60% (i.e. 40% of the oscillation gain) so it becomes 0.0667.
Here’s another nice pic showing both the slew rate and the desired vs actual turn rate. We can see the oscillation number spiking at the same time as the turn rate control starts oscillating horribly so at least we know the slew rate calculation is working.
The steering rate feed-forward also ended up higher than what you had originally. The tuner calculated 0.3775 but you had 0.24. This is not terrible but it could be inaccurate because oscillations are making the inputs to the calculation very noisy but I also suspect the FF gain should be slightly lower than “perfect”. Put another way, if we zeroed the steering turn rate P, I and D gains to zero so only the FF is used for turning, I think we’d want the actual turn rate to slightly underachieve the desired turn rate.
The final results for the steering turn rate tuning were:
- ATC_STR_RAT_D increased from 0 to 0.0667
- ATC_STR_RAT_P increased from 0.1 to 0.236
- ATC_STR_RAT_I increased from 0.1 to 0.378 (script bases this on FF value)
- ATC_STR_RAT_FF increased from 0.24 to 0.378
The speed controller tuning also calculated gains that were much higher than your manually tuned values. For example ATC_SPEED_P was 0.11 (your tune) but the script increased this to 0.73. On the bright side though the CRUISE_SPEED and CRUISE_THROTTLE (essentially the FF) was almost unchanged.
- ATC_SPEED_D increased from 0 to 0.0127
- ATC_SPEED_P increased from 0.11 to 0.73
- ATC_SPEED_I increased from 0.11 to 0.395 (based on FF)
- CRUISE_SPEED slightly decreased from 1.63 to 1.57
- CRUISE_THROTTLE slightly increased from 61 to 62
The velocity controller tune ended almost immediately because the SRate values were already very high. It ended up reducing:
- PSC_VEL_D reduced from 0.05 (your value) to 0.021
- PSC_VEL_P/I reduced from 0.8 to 0.28
It’s slightly questionable whether the oscillation was really all from the velocity controller or whether we were getting some oscillation actually caused by the high gains of the lower level steering and speed controllers.
2 Likes
Excellent! I can definitely say that oscillation persisted in both throttle and steering (independent of position/velocity control) because I drove in ACRO with the resulting gains and observed both. Log for that was not included.
Happy to run again with an increased gain margin and then as needed with an added FF margin param when it’s ready. Your suggestion about FF matches my tuning strategy when dialing things in manually.
I’ve always been displeased with the noise, especially in the speed input. That was my motivation to include FFT and HNTCH in Rover. Still, it’s a very noisy system, no matter what!
1 Like
Based on @Yuri_Rage’s feedback I’ve slightly updated the script:
- RTUN_GAIN_MARGIN has been renamed to RTUN_PD_GAINMARG and its value has been increased from 60% to 80%. This should result in significantly more conservative gains (half as high actually).
- RTUN_FF_GAINMARG param added resulting in more conservative Steering Turn Rate FeedForward gain. Initially set to 20%.
No changes to the C++ are required so the links at the top of the discussion are still valid.
1 Like
@rmackay9 You had made a comment about RTUN_OSC_SMAX and reducing it from 5 to 2. Is this still appropriate? I made the change before testing below.
Hoping to get out today for more testing.
Managed to get a Quciktune Run in with a before and after mission. You can see in the before mission this vehicle was pretty well dialed in. After the Quicktune changes not so much. It wandered around off course quite a bit. I didn’t have telemetry for some reason so I cut the session short but got some useable data anyway I think. Sorry for the extra loops I couldn’t tell when it was completed.
Redcat7 Quicktune
Will reset back to baseline. Will try again.
1 Like
Here’s a log with the updated gain margin params. I started with the same manual tune as before.
Initial observations are very positive. At the very least, it’s drive-able, but I think it may actually be a little tighter tune than I achieved manually.
Ran an AUTO mission and noticed right away that there was a lot of crosstrack oscillation on a pretty long period (slow drifting back and forth). The script settled on 0.175 PSC_VEL_P and I terms, but it got all the way up to 0.74 during tuning. Since we know oscillation should be present at 0.74, I manually set 0.6 for PSC_VEL_P and I, and nav is slightly better, though still a little “looser” than what I could achieve with NAVL1. Overall, it seems as if the PSC gain margins can be a lot tighter than the ATC rate term margins.
UPDATE - settled on:
PSC_VEL_P=0.65
PSC_VEL_I=0.65
PSC_VEL_D=0.03
Still imperfect, but better.
Did some more driving in ACRO after the mission, and, while I’ll hesitate to call the QuikTuned steering/speed params perfect, it’s behaving VERY well!
I’ve done a test with the following rover:
- mRo X2.1-777 flight controller
- Bogie Runt Rover frame
The script ran just fine on an F7 CPU, which is good.
I was a bit constrained where I ran the test, so I was doing 2m radius circles at 0.7m/s (it’s a slow rover).
Some combination of my M8 GPS and the tight circle made the circle tracking fairly bad:
Despite this, I got a fairly good tune for ACRO mode. It was definitely tighter than my previous manual tune.
I will try again in a larger area in the next few days.
Base params:
- PSC_VEL_D 0.000000
- PSC_VEL_FF 0.000000
- PSC_VEL_P 1.000000
- ATC_STR_RAT_D 0.000000
- ATC_STR_RAT_FF 0.400000
- ATC_STR_RAT_I 0.010000
- ATC_STR_RAT_P 0.200000
- ATC_SPEED_D 0.000000
- ATC_SPEED_I 0.020000
- ATC_SPEED_P 1.700000
After Quiktune:
- PSC_VEL_D 0.012120
- PSC_VEL_FF 0.305000
- PSC_VEL_P 0.448468
- ATC_STR_RAT_D 0.015600
- ATC_STR_RAT_FF 0.600000
- ATC_STR_RAT_I 0.702220
- ATC_STR_RAT_P 0.190288
- ATC_SPEED_D 0.002100
- ATC_SPEED_I 1.213277
- ATC_SPEED_P 0.763763
Steering control was pretty good (though maybe it was demanding a little more than the frame could achieve) after the tune too, though I need to work out why the lateral accel was maxxing out at a too low level:
1 Like
I have flashed this on a balance bot with Pixhawk1 (F4), loaded the lua script, getting:
and it doesn’t arm, so what is this Rover-4.5.0-DEV for Pixhawk1 07Jun2023 for, related to these tests?
Testing indoors (reduced space), with:
CIRC_RADIUS=1
CIRC_SPEED=0.3
it moves back and forth, thinks a lot, and moreless does the circle.
1 Like
I wish it would run on F4 but it simply won’t I am afraid of or I would have tested a bunch of F4 related flight controllers.
1 Like
Hi @Webillo,
Thanks for testing circle mode anyway. You’re right of course, there’s no way that the scripts will run on a Pixhawk1. I’ll remove that binary now.
1 Like
After a compass re-cal, the results got better, but still a 1m drift with the circle. To be expected with an M8N GPS I suppose:
(2.5m radius circle)
So, for a good CIRCLE mode, I need a larger radius circle and/or a better GPS. Fortunately, I have both in one of my (tougher) rovers. I’ll try that one next.
So I’d advise users to have at least a 3-4m radius circle and an RTK-capable GPS. Maybe with larger (10m radius circles), an average (ie M8N) GPS module would suffice.