Thanks for giving it a try. I wasn’t expecting you to find any significant change in behaviour besides a slight improvement in the delay before pivot turns so we will need to get to the bottom of this.
I guess the issue could be a change in the new SCurve feature, a change to master, an unintended parameter change or some physical change in the vehicle.
I’ve done a fair bit of testing in the simulator but I’ll put this on my AION robotics rover and see how it does and maybe I can uncover what’s happened.
No worries, happy to help. I have a small Ackerman-steer truck that I never tuned well. I was considering loading one of these S-Curve variants onto it and attempting a tune for comparison.
By the way, for Ackerman steering vehicles I hope to improve their performance in the future (not as part of this change) by adding an equivalent to the skid-steering vehicle’s pivot turn controller.
Below is a picture from the simulator in which the Ackermann vehicle was initially stopped at waypoint 1 (the corner) and then continued to the next waypoint off to the West. The yellow dots show that because the vehicle cannot physically move laterally we end up with I-term build up in the position controller which leads to overshoot below the line. We can fix this by adding a turn controller that plans the turn.
Just two other small things. Could you try master to see if the mission wipe problem occurs? If it doesn’t occur with master then it must surely be related to the parameter conversion code I added somehow affecting the MIS_TOTAL parameter. If it does still occur with master then we’ve got a much wider problem and I might ask another developer to help me get to the cause.
I forgot to mention that I changed the speed controller to set the ATC_SPEED_FF value from the CRUISE_SPEED and CRUISE_THROTTLE values. This shouldn’t have any effect but maybe I messed up.
I can definitely do that to check for waypoint disappearance.
I’ve been changing a lot of tune parameters throughout this process, aiming for the best results. This last change caught me off guard, and I probably did not tune as well as I could have, given the drastic change in behavior.
@rmackay9, waypoint issue solved! It was all my fault. The SD card was full and beginning to overwrite log files, and I guess current waypoints are discarded once that begins to happen.
Once I freed some space, everything was back to normal ops. I hope you spent little to no time investigating my own error!
Great! That is very interesting though… I really wouldn’t expect a full SD card to have that effect because on most boards (including the cubes) the missions are stored in eeprom along with the parameters. I’ll raise an issue and chat with @peterbarker about this to see if he has ideas.
Definitely wasn’t the first place I thought to look, but I noticed it was full before I returned it to the mower today, so I cleared it off a bit. Then it dawned on me to check waypoint persistence afterward…and it worked! (on your latest build from above, which I specifically tested on previous reboot cycles where waypoints disappeared)
The card has likely been full since the day I noticed the issue. My runtimes tend to be long, so the space fills somewhat quickly.
I’ve updated the binaries linked from the top description with some more changes:
SCurve path’s max acceleration is set to the lowest (non-zero) value from WP_ACCEL, ATC_ACCEL_MAX, ATC_DECEL_MAX and ATC_TURN_MAX_G/9.81. This should result in more conservative accelerations, decelerations and turns (which may or may not be good) but it should also always stay within the vehicle’s capabilities.
Speed nudging in Auto, RTL, etc works again (e.g. vehicle speeds up in Auto if pilot raises throttle)
Change speed commands from the GCS are consumed (they were being ignored)
Sailboats are working again in Auto, RTL, etc but if you use Guided please set GUID_OPTIONS = 64 to enable the use of SCurves in Guided mode (instead of the “Position Controller Input Shaping”).
Crosstrack reporting may be negative if vehicle is to the left of the path, positive if to the right (previously they were always positive)
This was quite a large update and completes the majority of the development I think. My hope is that from now on it will be relatively minor fixes that are required.
@rmackay9, there is definite improvement here! The pauses are less dramatic, but they are still present. Perhaps most concerning are the brief pauses at non-pivoted waypoints. The vehicle is easily capable of making those obtuse-angled turns at speed, and I think the parameters should allow for it, but it still slows or even stops at each waypoint. I tried quite a few tuning changes to try and improve performance. The log I will upload shortly is the best I could achieve.
If you pay attention to the GCS messages in the log, you’ll see some extra ones from a script I’m working on to report some tuning parameter suggestions - a feature I may try to develop into an autotune-ish mode for Rover. It probably needs some filtering on the sampled values, but I think there’s some goodness there!
Seems I spoke too soon regarding waypoint disappearance. I had a good test between reboots yesterday, but today we are back to having to upload waypoints between boot cycles. The SD card has plenty of space, so I can probably rule that out as a factor.
Re the mission-clearing issue, could you grab the latest @SYS/storage.bin as well? This is the full eeprom in raw form which includes parameters, missions,etc.
@rmackay9, storage.bin uploaded to the same Drive folder. The waypoint issue is now intermittent! When I booted up to grab the storage.bin file, the waypoints were still there. On the previous reboot when I made the .bin log for you, I had to re-upload the mission I’d been using all afternoon.
Txs for the log. So it appears that the bendy ruler object avoidance is the cause of the stops at waypoints (even those that don’t require a pivot).
I need to investigate more but I think what is happening is that the vehicle reaches the waypoint, then passes the next waypoint to bendy ruler and waits for a response. Bendy Ruler runs asyncronously so it can take a second or so to respond (depending upon CPU load) and during this period the vehicle stops. Once the response arrives it starts on its way again.
From a quick test master acts the same but I haven’t tested vs 4.1.3. This at least highlights that scurves corners still end up being stops if OA path planning is enabled (e.g. OA_TYPE is non-zero).
That makes sense, Randy. I did notice some “stuttering” at waypoints under 4.1 with BR enabled and never connected the dots. With S-Curve, it’s quite pronounced. I will get the mower out today and try disabling OA for comparison’s sake.
I’m happy to test with any variation of fence-based OA enabled/disabled as we move forward.
EDIT:
Can confirm - disabling OA removes the delay at non-pivoted waypoints. Pivoted waypoints still seem to be approached overly cautiously, even with fairly aggressive ACCEL values (up to 10m/s/s). It almost seems as if the vehicle gets a little “indecisive” as the waypoint approaches, slowing excessively and creeping up on it, then finally engaging the pivot turn. Maybe we can relax the “waypoint achieved” determination?
Also, it’d be really interesting and probably necessary at some point if you have some documentation (or could write a bit more of a primer) on the position controller and how the PSC* parameters should be tuned for navigation.
I’ll do some more comparisons vs master of the vehicle’s behaviour during a pivot turn discuss more with Leonard especially re the pre-pivot part.
Yes, I totally agree about the PSC_ parameters although I also hope that we can find a combination that works for almost all vehicles I’ve got a small improvement to “limit handling” that I’m working on that may help a bit too.
I’ve updated the binaries linked at the top of this discussion with a new version (with suffix “12Jan2022”) that includes:
SCurve “jerk time” shortened from 1 sec to 0.1 sec. I hope this will reduce the delays we’re seeing before pivot turns
Position controller velocity limits to reduce overshoot. This should make tuning easier by ensuring even if the gains are too high, impossibly high velocities are never requested
Position Controller + Simple avoidance fixes and enhancements. The vehicle should properly backup now if it gets too close to a fence. I’ve also tentatively enabled AVOID_BEHAVE=0 (Slide) allowing the vehicle to turn a bit to get around obstacles.
By the way, I played around with the PSC_* tuning at various speeds in the simulator and especially with the new “Position Controller velocity limits” the results can be subtle
PSC_POS_P (converts position error to desired velocity)
higher values increase accuracy of driving along the path especially when close to the line
very high values on Ackermann vehicle leads to circling as small errors are exaggerated into large forward-back speed changes but also turns. On skid steering vehicles high values don’t cause many problems but maybe lead to some wobbling on the path or unhelpful random turns when very close to the waypoints
very low values lead to smoother driving but the vehicle ends up off the path
PSC_VEL_P (converts velocity errors into speed changes and turns)
very high values lead to oscillation on the path much like high PSC_POS_P
very low values lead to an offset off the path
BTW you can monitor the this controller in real-time by setting GCS_PID_MASK = 64 (or 128). Sadly this is a 2D controller in North-East frame so you can only look at Northern or Easterly performance not both at the same time.
PSC_VEL_I
very high values lead to oscillation on the path
very low values lead to a consistent offset off the path
my guess is that this should always be some ratio of PSC_VEL_P (like 20% of PSC_VEL_P)
PSC_VEL_D
higher values slow the vehicle’s return to the path but keep the vehicle driver straighter which looks nice.
very high values lead to unhelpful turns in the wrong direction at waypoints
very low values (like zero) aren’t too bad but probably lead to more wavering across the line
FYI, I’ve updated the links again just now to “12Jan2022b” based on another discussion with Leonard about the “Position Controller velocity limits”. This most recent change is quite minor though and doesn’t change any of the advice or discussion above.
