I’ll venture a guess that weather/surf conditions were significantly different between your previous, very clean results, and the more recent, uglier nav tracking.
It’s very possible that under calmer conditions, you were able to aggressively increase the position controller gains without penalty. I’m guessing you had a northeasterly or southwesterly wind on the subsequent run, which caused enough disturbance to set up the observed oscillation.
If the wind/weather conditions were near identical, are there other factors that changed between the two sessions? Physical changes to the vehicle, other parameters changed?
Before we simply blame the firmware, we have to look at factors that may have contributed to the observed difference in behavior.
Another difference - your first test was nearly all sharp corners, and I’m assuming they were pivot turns, whereas the second included many shallower turns. Perhaps the pivot turn parameters are well defined but the acceleration values for shallower turn angles need some attention.
Sorry I haven’t looked at your log yet (it is “golden week” here in Japan so I’m not around as much). I’m pretty sure this is just going to be “disturbance rejection” issue. So we may need a big more P, I and maybe some D in either the turn rate controller or the position controller parameters.
With the help of Randy giving assistance live on the water we managed to get AIMy to run much better on the straights with minimal ‘wobble’ less than 0,7m.
On a larger more complex mission the turns to starboard (right) seem pretty good …
I think I’ve discovered the root cause for the sometimes violent oscillation that happens when my mower exits pivot turns and I’ve got the position controller tuned a bit more aggressively. The front wheels are on casters. When there is a pivot turn of any significant angle, those wheels are still canted when forward motion resumes, resulting in a “nudge” to one side as they straighten. It’s that nudge that seems to set up the oscillation.
I wonder if better results might be possible if I use a Lua script to dynamically update the position controller’s D term? In other words, set it near zero when speed is near zero, then set it to a more appropriately tuned value once the speed increases a bit (which would presumably be after that front wheel nudge).
Are your props counter-rotating? If not, I suspect turns in one direction might perform slightly differently than turns in the other, and you may be stuck with finding a happy medium.
Decided to take AIMy (SKII) for a quick test before being sent off on a project, and the results were terrible.
Nothing has been changed (at least that I know of).
Something I did notice is that she was slowing down unnecessarily for slight heading change wpts, where she was only doing that on tight acute angle heading changes before.
I’ve been trying to get an AgileX Scout Mini working with S-Curve, but I seem to be having issues with the L1 controller. The heading for the next goal wanders all over the place in Mission Planner, which seems to be causing the robot to wander around. Usually it heads up heading in a southerly direction, but I don’t know if this is simply coincidental: I don’t have access to a larger area at the moment to run larger scale tests.
The params I’m using have worked before, with some simple waypoint following around some small copses of trees and performed reasonably well with the rover-42dev-scurves-matekh743-05Mar2022 firmware, so I’m not sure what I’ve messed up for the robot to display this behaviour.
I tried the params @Yuri_Rage suggested, but didn’t seem to have an appreciable effect. If someone wouldn’t mind have a glance over the attached logs, I’d much appreciate their input on the problem!
Updated, and the rover reversed immediately, as soon as I allowed the flight controller to command the motors to start the plan (separate switch on the joystick, by-passing the flight controller). This happens even when it is disarmed in Mission Planner.
I inspected the servo data, and the throttle seems to be sitting at 0, ignoring the trim being set at 1500 and the min value. I can’t confirm if this behaviour is the same in both auto and manual, as manual is not in the mode list (I noticed that sometimes the modes are what I believe to be ArduCopter, instead of ArduRover. It sometimes corrects itself after a little while, but not all the time, and updates the mode list.).
With the throttle being set to 0, that is full reverse, and it doesn’t seem to be updated at all during plan execution, though the Ground Steering seems to be working. Same params loaded.
ARMING_REQUIRE is set to 1, so when disarmed it should be sitting at THR_MIN_PWM… But this doesn’t seem to be the case.
Maybe that will fix it.
