Reduce "fishtailing" (weaving) on Full Size Autonomous Cataraft With Torqueedo Cruise 3.0, Vector Thrust

[Hatchmandu (Gerry Hatcher)]

Hi All Thanks for any help. And please point me in the right direction if there’s an existing post that includes the information I’m after…

I’m having difficulty with getting turning parameters correct for my cataraft mapping boat project inspired by @rmackay9 posting: DeSET mapping boat in Okinoshima Japan

I’ve spent many hours over several days at a nearby lake trying to get the parameters correct following the First Drive with Rover / Tuning Turn Rate instructions. I can’t seem to get rid of the fishtailing. All I can do is make it worse by changing things when the boat is in any one of the autonomous modes.

I’m providing the GNSS Ntrip corrections from a local CORS GNSS base station through mission planner so the navigation is almost entirely fixed RTK. Ive calibrated the compass with large vehicle calibration and acceleration calibration of “calibrate level” and “simple accel cal” when the vehicle was level on the trailer before launching - they were both successful.

There is occasional wind of about 8-10 mph by mid day but early it was dead calm and there was not a noticeable difference in line following ability. The Torqeedo motor is very powerful for this rig and has no trouble pushing it around.

I’ve started with defaults of 0.2 for P & I, 0 for D, 1.0 for Imax and ranged FF from 0.0 to 4.0.
I’ve also moved ACRO_TURN_RATE from 5 to 90 (I think about 15-20 is what it should be based on watching pidachived vs piddesired in acro mode.

In manual or acro the boat can be driven well. It is very maneuverable and tracks straight but in circle mode, drive to here, or survey in auto it fishtails as seen in the screen grabs below - the first one demonstrates where I modified FF while underway where the fishtail amplitude was much higher. For scale the line spacing shown is 10 meters and the circle radius is 20 meters.

Note that the yellow & white Trimble GNSS antenna shown on the front of the boat is Not the one used by the autopilot. There is a smaller dedicated antenna on top of the white Yeti cooler about 0.5m directly in front of the cube orange which located inside the electronics box with the transparent lid. The antenna a high quality talllysman 33-7972-00 GNSS antenna but has a mag mount so I couldn’t place it directly above the cube orange without the compass being bothered.

The frame on the front gets lowered to the position seen in the video once the vehicle is away from shore so the tubes are submerged ~0.5 meters below the water surface during normal operation/survey. I did all of the testing/tuning with the tubes deployed but did try with them up out of the water to see if there was much of a difference and the answer was no.

A video of the system operating in ACRO mode [P=I=0.05, IMAX=1.0, FF=1.0] can be viewed here:

IMG_0393.MOV

A close up video of steering the motor via RC control is shown here:

IMG_0394.MOV

Parameters:
LochLomondEndofDay16Apr2025.param (15.6 KB)
Note- Acro_Turn_Rate and the ATC_STR_* parameters were modified several times during data included in the log files below]

Logfiles:

00000087.BIN

2025-04-16 11-06-15.tlog

System:
Cube Orange autopilot with Rover/Boat firmware recently updated.(6 months)
Septentrio Mosaic X5 GNSS (operating in RTK mode)
Torqeedo Cruise 3.0 R
Herelink remote control and air-unit.
Custom steering mechanism using Pololu Tic 36v4 stepper motor driver to power a high torque Stepper connected with a modified rack-and-pinion steering system operated as a steering servo.

If anyone would like more information I’m happy to provide.
Thanks for reading
Gerry

[amilcarlucas]

I corrected the title to be shorter and more descriptive

[rmackay9]

Hi @Hatchmandu,

Sorry for the slow reply, I’ve been thinking about this one a bit.

I think the most likely cause is a delay in the throttle or steering response.

I guess the torqeedo is being controlled using the Lua script? I see TRQD_TYPE = 1 but perhaps you’re not using the Torqeedo adapter board?

[rmackay9]

I also wonder if you’ve tried the QuikTune script?

Because this is a vectored thrust vehicle any issues with throttle control can also affect the steering. This is where a slow response from the throttle could cause issues.

I guess you’ve also already completed the speed and throttle tuning? I wonder if you could try driving it in a straight line using Acro mode at a few different speeds?

If possible I think it would also be good to remove the limit on the throttle. MOT_THST_MAX is currently set to 60 and we see that the motor is very regularly hitting this limit.

Because of the turning, it’s difficult to tell if the CRUISE_THROTTLE and CRUISE_SPEED are set correctly. At the moment CRUISE_THROTTLE=21 and CRUISE_SPEED=0.78 which implies a top speed of about 3.7m/s (at 100% throttle) which seems reasonable actually. BTW, the wiki says to put the throttle at 50% to 80% but I often just use full throttle. I’ll update the wiki to reflect this.

After we’re sure the turn rate and speed controllers are working as well as they can we can investigate the navigation tuning. I suspect that for some larger vehicles with slow response the advice that states, “PSC_VEL_FF should always be 0” is incorrect and that setting this to a value as high as 1 may help.

[Hatchmandu (Gerry Hatcher)]

Hi @rmackay9 Thanks for the reply and your time, no problem on response time. I can only test on Wednesdays because my lake access is at a local state park that’s closed to the public on Wednesdays but I’ve been granted access for this project.

I’m controlling the Torqueedo throttle using serial connection from the cube orange carrier board through a board that converts the TTL to 485 but if there’s a Lua script under the hood I didn’t realize it I thought it was a torqeedo driver added to the Rover firmware. But I’ve not had to implement anything fancy, it just worked

The boat hull speed is slow, ~3.7 m/s is achieved with about 50-60% throttle and 100% only gets to about 4.0 m/s with a bunch more water churning around and much faster battery depletion. But I’ll give it a go without limits.

When I look at pidrequested vs pidachived, pidachived is always lagging but the amplitude looks decent. I wonder is there a parameter I’m missing that slows down how fast pidrequested changes so that the boat could better keep up?

I tried the QuickTune script. It seemed to work okay for the throttle but if I remember correctly it never finished with the turn tuning. I’ll try driving in a straight line in acro at different speeds and upload a log as well as give the quicktune another shot. I was starting to feel that possibly quicktune only worked for land based vehicles so I moved on, maybe prematurely.

My next trip to the lake is likely April 30th.
Thanks again and I’ll update this topic after my next text with any success or failures in case others may be watching.

[rmackay9]

Hi @Hatchmandu,

ok sounds good. So you must be using AP’s built-in torqeedo driver which is fine. Sadly the protocol for the Cruise appears to be slightly different than for the Travel so we don’t get feedback from the motor. That’s not a critical blocker though, just a little inconvenient.

[Hatchmandu (Gerry Hatcher)]

Hi @rmackay9
In preparation for my next on the water test I realized that something that has given me problems with using quicktune.lua is I couldn’t find a recommend set of starting values for the “Basic Tuning” PID parameters so I wasn’t confident I was using the script correctly. So is there a recommended starting set of values?
Thanks!

[rmackay9]

Hi @Hatchmandu,

I think the vehicle’s current tuning values will be OK. The most common issue that users face is that the script complains that the vehicle isn’t turning quickly enough. This can be resolved by changing the circle radius as mentioned on this page Circle Mode — Rover documentation

[Hatchmandu (Gerry Hatcher)]

Hi @rmackay9,
I’ve got results from testing my torqeedo powered cataraft last Wednesday.
The executive summary:

1, I was successful in getting the vehicle to autonomously navigate acceptably straight survey lines and do nice circles, screen grabs attached. However, I arrived at the tuning parameters via trial and error and don’t have confidence that they’re done correctly and thus robust for most/all weather and current conditions. I did find that setting GPS_POS1_X =-0.77 helped. I since the antenna is in-front of the cube orange I thought this should be a positive number but that made weaving return.

2, Quicktune.lua did not generate good values for this vehicle. It ran successfully and finished without error, but the vehicle still weaved unacceptably after the values were saved. - I’ve included link to a data flash log where I ran it twice in a row in case that is of interest to you.

3, I also saved a data flash log where I ran the vehicle in ACRO at two speeds as you requested. link below.

So, as I mention in 1 I’m not confident I have good numbers primarily because the pidrequested and pidachieved don’t track each other well even when line following is good. During operation I’ve got a live video stream through the herelink control from a camera pointed at the motor, and I can see that the steering motion of the motor is nice and smooth - no crazy oscillation or jerking of concern.

If you or someone else has time to take a look at the logs and check for anything obviously crazy or have suggestions, I’d be incredibly grateful.
Parameters Files:
Starting Parameters - used at start of QuickTune.lua

parameters saved from quicktune.lua

Parameters saved at the end of the day after trial and error tune

Data Log:
TLOG for entire day of test

DataFlash Logs:
ACRO at two speeds flash log
~19:21:20 → 19:22:30 ACRO, straight line at diff speeds.

Log of QuickTune Runs
~19:27:50 QuickTune start first time
~19:32:00 QuickTune run again

Log of good line following
~22:06 to end

Log of circles
~21:58:00 circle mode

Pictures:
Start of day with weaving

!

After trial-and-error tune

Circle Mode

Auto LineFollowing

Thanks!!
-Gerry