We’ve included the Rover QuikTune in Rover-4.4.0-beta4 which should appear in the ground stations within the next few hours and then it can be installed using MP’s beta firmwares link.
I plan to have a look at your logs tomorrow. Again, sorry for the delay.
That is awesome, thank you Randy. I plan on testing again next week Monday.
Hi @John_Easton,
I had a look at yours logs and it appears that the CRUISE_SPEED and CRUISE_THROTTLE values haven’t been set. The QuikTune will set these for you though when you run it so let’s see how that goes.
The steering rate controller is under achieving fairly badly. So for example the upper navigation controls are asking the vehicle to turn at 40deg / sec but the vehicle is only turning at about 10deg/sec.
This next graph shows the FF, P and I contributions to the output. The balance of the three is not bad so I think they’re all basically too low. At least ATC_STR_RAT_FF should probably be doubed from 0.15 to 0.30. Again the QuikTune could figure this out.
By the way, it would be good to tell the controllers the limits of the frame by reducing these parameters:
By the way, one thing regarding the frame, it would be good if the vehicle could turn more quickly. I think 10deg/sec max turn rate means that the controller has very little power to correct deviations from the path.
Thank you very much for taking the time to review my log Randy, and I agree, a good tuning will make a big difference.
I tried the QuikTune yesterday but I got a strange error - “Tune needs to be armed and moving”, but the craft was armed and moving - here is the log for that test:-
With regard to the frame, the motor has been set to its maximum turn angles possible.
Another interesting fact is that on Rover4.2 this same craft used to go dead straight on the straights and make fairly accurate turns using the old L1 controller.
Hi @John_Easton,
The message, “Tune needs to be armed and moving” is displayed when the RC switch is in the middle and the throttle is zero. So one unintuitive thing about the script is the RC switch positions (RC6 on your transmitter I think):
Low: Disabled
Mid: Enabled (e.g. starts tuning)
High: Save tuned parameters
So I think while the vehicle was in circle mode the switch was in the high position. Then later on while the vehicle was in Manual mode the switch was moved to the middle and the message appears.
So should this be the procedure?:-
a - RC6 low / disabled
b - change to circle mode
c - change back to manual mode
d - RC6 mid / enabled
and when complete - e - RC6 high / save
The procedure should be:
a - rc6 low / disabled
b - change to circle mode
c - rc6 mid / enable
d - wait for the tune to complete. It should save parameters but if not rc6 high
e - rc6 low / disable
f - Acro or Auto to test tune
… so the key thing is that the QuikTune should be run while the vehicle is in Circle mode. I will change the script to enforce that in the near-ish future.
Oh ok, roger that. Makes sense now.
If I upgrade my firmware to 4.4, will I loose all my existing parameters?
I really don’t want to redo all those after spending months to where I am now.
I am keen to try the script with maybe some help to install it.
Hi @Fossil,
Thanks for getting involved in the testing of this new feature!
No, parameters should remain intact even after a firmware upgrade. Upgrading the firmware does not erase the eeprom which is where parameters are stored unless firmware for a different vehicle (e.g. Copter, Plane, Sub, etc) is loaded onto the autopilot.
By the way, saving all parameters to a file is quite easy using MP’s Full Parameter List (see “Save to file”) button but it is rarely needed.
Parameters are also stored in the onboard log files (aka dataflash log files, aka .bin files) which are stored on the autopilot’s SD card and can be extracted using MP’s Data screen’s Dataflash Log’s tab’s “Create KML + gps” button.
… so even if parameters were erased (which they probably won’t be) they can nearly always be retrieved.
Perfect. Many thanks @rmackay9. I will re-read the whole thread and attempt to follow the instructions.
I still have to overcome my lack of servo output first! Very frustrating,
Cheers, Martin
I managed to get out on the water this morning but I must be doing something wrong …
Here is the log - 00000009.BIN - Google Drive
Hi @John_Easton,
Thanks for giving it a try.
It looks like it partially tuned the vehicle but it could not complete the steering “feed forward” tuning because the vehicle was not turning aggressively enough. You might have seen the message, “RTun: increase steering (6% < 10%)”.
The solution is to make the circle tighter by reducing CIRC_RADIUS from 20m to perhaps 15m or 12m.
By the way, I noticed that the vehicle is setup to use EKF2. My guess is that when the vehicle was setup you perhaps just blanket copied all parameters from an older vehicle. It’s probably OK but in general we don’t recommend doing this. Instead we recommend more targeted copying of parameters. For example attitude control parameters all start with ATC* so you might only copy those. Could you switch to EKF3 by setting these parameters?
For what we’re doing here, there’s no real significant difference between EKF2 and EKF3 but it’s good to be using the latest “estimator”.
Thank you for the feedback Randy, I will try that today.
thanks for the script. I tested it today on CubeOrangePlus + Rover 4.4.0-beta4 .
SRC_ENABLE=1
CIRC_DIR=0
CIRC_RADIUS=20
CIRC_SPEED=6
but in my boat for some reason the counter-clockwise direction was mixed. and the script gave an error so I couldn’t configure anything.
Critical: RTun: Internal Error: /APM/scripts/rover-quicktune.lua:633: attempt to call a nil value (method 'get_steering_and_throttle')
Are you sure you have 4.4-beta4 loaded? This seems to indicate a version mismatch (maybe a 4.3 version was accidentally loaded).
Stack: ArduPilot
Vehicle: Rover
Version: 4.4.0 beta
Git Revision: 1c5c94f9
Not reproducible in SITL. That version should have the vehicle:get_steering_and_throttle() binding so far as I can tell.
A log file would likely help.
@rmackay9, any ideas?
I can’t see why that wouldn’t work so a log file would be good to see.
Unfortunately I can’t provide the log files. But I tried again today and this error was gone. The only thing that remained strange was that the boat always moves counterclockwise. that I could not finish the whole process until the end of the script because of GPS problems
