John Easton's boat navigation


I’m sorry you’ve been having issues with it, but I think it’s worth troubleshooting it. I don’t want to branch off topic from the navigation issue too much, but could you point me in the direction of your previous posts on the telemetry problem?

As a reference, I would recommend updating the Sik Firmware using the instructions here:

1 Like

Thanks Nathan, I will spend some time with it again this week. Much appreciated

Holybro has kindly offered to send me this boat which I think/hope has a steering control live @Fishton’s. I have some code that should better scale the steering output based on the throttle but I want to test it before sending to JohnE.

I’m a little worried now that I re-check the pictures that this boat’s thrust doesn’t move with the steering. Thoughts?

Edit: it seems like at least some versions of this boat have a link in the gear shaft to handle the turn so it should be OK.

Yes, that certainly will be very close to my steering type.

The only thing that will be vastly different is the amount of torque/thrust that is produced by my prop/motor that I believe is part of the problem.


If you’re feeling a little brave I wonder if you could:

  • load “master” (aka “latest”) onto your vehicle by going to the Mission Planner’s Install Firmware screen and press Control-Q, The caption under the Rover icon should change to “ArduRover V3.3.0-dev”, then push the Rover icon.
  • connect with a ground station and set the MOT_VEC_THR_BASE parameter to 30.

What this will do is replace the scaling of steering response based on vehicle speed with a scaling based on the motor output.

The meaning of MOT_VEC_THR_BASE = “30” is that steering response is not reduced while the throttle is below 30% and at full throttle, the steering response is 30% of the full range. 30% is probably too high, 20% might be better but there is a slight danger that if set too low, the vehicle will lose steering control at full throttle.


TBH, I need to get our controls expert (@lthall) to review this but I think it makes things better if not exactly perfect.

Please be ready to re-take control in manual mode in case things don’t work out. I’ve tested it though and it seems OK to me.

Wow Randy, huge improvement! (Rover 3.3.0 Dev)

Other than two spots where it went a bit wonky, it performed brilliantly, even in the choppy conditions.

The first pass of the mission, from WPT#2 to WPT#5 things were VERY wobbly, then things started to smooth out.

In the video below, it starts at WPT28 where it takes a sharp cranking turn, then immediately another at WPT30 and as it started to straighten out it just lost the plot entirely! Not sure what happened there.

With the Google Earth overlay you can see the track on top of the mission …

Then after that it was plain sailing as they say …



Thanks very much for testing this! I’ve merged the change to master and I suspect we will add it to Rover-3.3.

The wobbles at the start and wonky-ness around WP 30 are interesting. If you get a chance to provide a log I’ll have a look.

Very good news though in that this test pretty much confirms we needed a different scaling of the steering response. I think we can improve it further … for example reducing the MOT_VEC_THR_BASE to 25 or even 20 will probably work. and for boats that have a rudder placed dirctly behind a fixed motor, they probably need a blend of vehicle speed vs motor thrust to get the perfect response.

Apologies Randy, I forgot to attach the log -

I will certainly try both 25 and 20 and give you feedback.

Some might say “Why do you need such accurate steering?” The reason is not for simple depth/position/bottom hardness/weed-line survey data, as this is captured using down looking cone shaped sonar.

However, for sidescan sonar beams with a total reach of 300ft from side to side, the slightest turn causes blurring, especially on the outer ends of the beam.

While zoomed out, these images below might seem fine, but when you zoom in close, the quality is lost due to the slight wobbly path.

1 Like

Great work Randy Rover 3.3.0 dev is must have for boats with MOT_VEC_THR_BASE param.

1 Like

1 Like

Now sideimaging looks much much better

1 Like

@Plastic, Nice video! Thanks for sharing, love seeing those.


I finally got a chance to look at the logs you provided and interestingly it is a compass issue (I was expecting it to be a control issue but it’s not).

The graph below shows the period between Waypoint 30 and 32. It’s a graph of desired turn rate (blue) actual turn rate (green) but more importantly the vehicle’s estimated heading (red). This heading suddenly jumps from about 150 degrees to 300 degrees at the same time as the “EKF2 IMU0 ground mag anomaly” message appears. So the EKF is confused about the heading so it suddenly switched to the internal compass and that caused the vehicle to turn off course. It figured out the problem after a bit and returned to the actual heading but in any case, this is the cause of the vehicle turning off course.

So two things to improve the situation:

  1. re-do the compass calibration. It looks like the “live” calibration was done but ideally the “onboard” compass calibration should be used.
  2. disable compass2 and compass 3. There are a couple of check boxes in the middle of the compass calibration screen in MP in case that helps.

Txs for the feedback and logs.

We’ve just released Rover-3.3.1-rc1 for beta testing that includes the vectored thrust feature. Any confirmation that it seems to work would be greatly appreciated. basically it should work just like the previous 3.3-dev version you tested with last time.

Strange that the compass should do that, then return to normal.

Thank you for checking those logs, and yes, I will do a onboard calibration.

I am tied up for another week or so at work, but can’t wait to test it again.

Will supply feedback as soon as it is done.

Thank you once again for everything you are doing for this project.

1 Like

This is great news -
Rover-3.4.1 has been released as the official/default firmware and will be available through the various ground stations (Mission Planner, QGC, etc) in the next hour or two. It can also be directly downloaded from

Changes vs Rover-3.4.0 can be found in the Release Notes2 and are also copied below:

steering output caps removed (previously limits could result in wide turns on fast vehicles)
lane based speed control (vehicle slows to stay close to line between waypoints), WP_OVERSHOOT replaces SPEED_TURN_GAIN
MOT_SPD_SCA_BASE allow configuring speed (in m/s) above which speed scaling begins
disable acceleration limits when ATC_ACCEL_MAX is zero
accept DO_CHANGE_SPEED commands in Auto, Guided, RTL, SmartRTL
DPTH dataflash log messages for recording downward facing echosounders on boats
If you have any problems with this new version it is possible to install Rover-3.4.0 using the Mission Planner’s “Pick Previous Firmware” link on the Install Firmware screen.

Thanks again to those who helped test this new version1.

1 Like

I will do some comparative videos from the air when I test this on my craft.

Great work Randy, I’m holding thumbs!

1 Like

Did some testing with the latest 3.4 and made no other changes.

Both trails together -

Just 3.4 - As you can see a VAST improvement except for that one little hiccup.

Just 3.2 - This is too unreliable and causes massive waste of time when mapping.

Zoomed in you can see how far out it was -

1 Like

Ah, this is really great. Really happy that we’ve improved the performance.

The little loop is interesting. It looks like it turned the wrong way. My guess is the vehicle lost steering control or the steering response was temporarily backwards. In either case it was probably caused by the vehicle trying to slow down quickly as it reached the waypoint and perhaps it was floating with the current at that point.

So maybe the throttle controller was trying to slow down the vehicle so it reduced the throttle to near zero but with the motor not spinning much, it has almost no steering control. The boat mostly drifted but once its heading naturally turned off the line, the steering and throttle control kicked in again and got the vehicle back on the line.

Two other possibilities are:

  • we have a bug in vectored thrust code which gets the steering output direction backwards when the motor is running in reverse (issue raised here)
  • the steering/throttle controls thought the motor was spinning backwards but this vehicle can’t actually spin the motors backwards (issue raised here)

Anyway, if you have a log we can figure out which of these possibilities it is but even without logs we can test these items in the simulator.

Thanks again for all your testing and feedback!

I will upload a the log later today.

Very excited about this update, awesome! Thank you

Unfortunately the WOBBLE IS BACK!