Rover-4.3.0-beta1 released!


Thanks for the report. These are really both ground station issues but in any case, yes we need to update Mission Planner’s Basic Tuning screen to match the new S-Curve navigation parameters. I’ve added this to our 4.3 issues list.

By the way, those parameters do not exist any more and instead we have different parameters for tuning the position controller. I plan to update the wiki to provide advice on this.

Re the flight mode display, I tried to reproduce this but on my Mission Planner it seems to be working OK. I wonder if you could try again and make sure that you’ve got an internet connection. I suspect the problem is temporary but if it keeps happening we can raise an issue with Mission Planner developers.

1 Like

First of all thanks for your reply.
I have switched computers and tested many times, and this problem has always existed. Hopefully it will be resolved by updating the ground station. Please let us know the wiki link for the S-curve and other parameter descriptions for subsequent updates.
thank you very much!

1 Like

Thanks for the update, you listed support for the Mamba F405 Mk4 does that include the mini 20x20 version?

1 Like


I’m not sure but maybe @andyp1per knows because it appears he added support for this board.

EDIT: ah, looks like you’ve already discussed with AndyP over on the Copter release discussion.

Yes he responded there, thanks. Still not sure whats the difference between version A & B he speaks of tho.

Here are two mission tests, indoors, without GPS, using Pixhawk1’s compass, with two balance bots:

and three balance bots:

all with ArduRover v4.3beta 20220913.

Tuning parameters was essentially:

  • Starting with v4.2.3 parameters, all balance bots start oscillating heavily back and forth, even disarming by itself (CRASH_ANGLE=45). These oscillations are stopped increasing ATC_BAL_D to around 0.5, but this causes a lot of vibrations and noise (motor gearing teeth are heard knocking exactly as in here (ArduRover v4.3dev firmware dated june 16)).
  • Teeth knocking can be greatly reduced increasing ATC_BAL_P and ATC_BAL_I and reducing ATC_BAL_D, and enabling WRC_ENABLE with a slow rate PID for both wheels, such as:
    with a lot of “Parameter outside range” messages.

Is there an easier way?

In adition, at times there are communication failures such as this:
at t=305 on the second video (three balance bots), which has happened always (they last a few seconds) and I wonder if it has to do with the wheel encoders code, so I think that optimising the duration of its irq handler as described above can be tried.

1 Like

Here is another video with a test mission, indoors, without GPS, using Pixhawk1’s compass, of the three balance bots:

but this time with the irq handler modified as described above, including additionally a modification for the rounding division μs->ms (add the remainder to the next conversion).

The files modified in libraries/AP_WheelEncoder are:

  • WheelEncoder_Quadrature.h,
  • WheelEncoder_Quadrature.cpp,
  • WheelEncoder_Backend.h,
  • WheelEncoder_Backend.cpp,
  • AP_WheelEncoder.h,

and can be found here. CAUTION: I don’t know the code (even I don’t know a proper place to initialize the remainder to 0, although possibly the compiler does it, and is not too important).

Anyhow, possibly the best would be to work entirely in μs, including the SITL encoders simulation (surely with a compiler error with above files (_state change)).

1 Like

Hi @Webillo,

Txs for this. It’s still on my to-do list to produce a PR with the changes and ask you to test. Sorry about the delay I’ve got a search & rescue competition in a couple of weeks that is consuming a lot of my time.

Had an excellent test/tune session with the mower and 4.3-beta1 this evening. I was finally able to increase the PSC_VEL_D value to a point where oscillations are well dampened under S-Curve nav.

There is a bit of an annoyance with having a high D term for the position controller on a vehicle with castered wheels (such as a zero turn mower). After a pivot turn, the casters are very misaligned with travel direction. When forward speed is commanded again, the casters very quickly align with the direction of travel, but not before momentarily “kicking” the vehicle in the previous direction of the pivot turn, which sets up an oscillation that the D term must fight. At a high PSC_VEL_D value, that “fight” becomes violent.

I wrote the attached Lua script to help tame post-pivot behavior while still maintaining straight line tracking at speed. It reduces PSC_VEL_D when speed is low, then increases it when speed is regained.

rover-PSCTuner.lua (3.3 KB)



I wonder what you think about this possible fix? It is done a little differently than your suggestion but I think the result is probably the same. Essentially it just keeps all the timestamps in microseconds. The EKF only consumes the timestamps in milliseconds still but I think it should be OK because overall, any remainder will be passed to the EKF eventually.

I fully agree that the best is have everyting in μs, so also in the wheel encoders signals interrupt handler (and the SITL simulation). Anyhow, I don’t know the code but I downloaded your code from GitHub and compiled it getting:

Target         Text (B)  Data (B)  BSS (B)  Total Flash Used (B)  Free Flash (B)
bin/ardurover   1395052      2116   194708               1397168          683584

for a Pixhawk1.

I tested it on a mission indoors (rover balance bot, no GPS, using wheel encoders and the Pixhawk1 internal compass):

As in here, it completes a lap and a bit more. Obviously wheel encoders positioning doesn’t last forever.

To test on your code the monolythic irq handler with code simplifications, no call/returns and no division μs->ms, I substituted the five files above, resulting:

Target         Text (B)  Data (B)  BSS (B)  Total Flash Used (B)  Free Flash (B)
bin/ardurover   1395016      2116   194704               1397132          683624

(40 bytes less, even with the remainder computations)
and tested the same mission:

with almost identical results.

BTW1, note that function AP_WheelEncoder_Quadrature::pin_ab_to_phase() in WheelEncoder_Quadrature.cpp contains two code alternatives and the not executed one is incorrect. The correct code can be put in a single line within the irq handler as:
uint8_t phase_after = (last_pin_a_value?(last_pin_b_value?2:3):(last_pin_b_value?1:0));

BTW2, tuning could be improved if I knew how (compromise tilt oscillation/motors teeth knocking, possibly worse at low speeds in above videos).

BTW3, the lap is quite difficult with reduced space, having to pass four doors (D1, D2, D3, D4) and passing beside a refrigerator R which affects the Pixhawk1 internal compass:

1 Like


Great, thanks very much for testing and pointing out the other issue.

So just to be clear, in your testing, the new branch performs better than Rover-4.3.0-beta1? The balance bot is able to travel further indoors using the new branch?

1 Like

I think externally they perform equal, with no new errors. I don’t know the program, so can’t see processor occupancy, or if some parts take a lot of time. I think moving to μs is an excellent decision. I think calls/returns/branches at code executed frequently (specially irq handlers) is like reactive energy.

The 40 bytes saved above can mean a lot in processor time saved.

Please, see this video:

It corresponds to a very easy wheel encoders test, and it even doesn’t require arming. Place the balance bot (with parameters those for wheel encoder position estimation) over something so that you can move easily one wheel. Have the MP hud show the coordinates and start with known ones. Mark the wheel for knowing the origin for those virtual coordinates.

(For that balance bot in above two videos the motors have CPR=11, and for the last coordinates figure to move one unit the wheel has to be moved around 1/8 turn. The virtual coordinates are (40.1 -3.1), somewhere in Spain (choosing the north or south pole can be funny). In the video the right wheel is moved.)

Now move the chosen wheel one turn CW and one turn CCW: the start and end coordinates should be the same, but the latitude shows errors (it is not the same). The version tried in the video is your version with the irq handler optimization. Repeat with 10 turns CW and 10 turns CCW (as in the end of the video (see the video index)).

So if the latitude has no errors and your code with the irq handler optimization makes no latitude/longitude distinction, everything should be correct, but there is elsewhere some error or lack of precision for the latitude coordinate; I have no idea where. Solving it can permit longer wheel encoder positioning based missions.

I’ll respond to myself: I had an error in WENC_POS_Y/WENC2_POS_Y measurement. Correcting it it seems that both coordinates maintain values. I’ll keep testing shortly.

1 Like

I have a few hours/acres on the mower with beta1 and have no major issues to report.

However, I think it’s worth discussing my aforementioned post-pivot turn oscillation issue when a vehicle has caster wheels. @rmackay9, this is likely a common enough physical configuration to warrant a firmware-level fix rather than relying on a Lua script.

I’ve attached an updated copy of the script that alters PSC_VEL_D for some distance following a pivot turn. I’m referring to the desired post-pivot behavior as a “nudge” - a short rollout distance to allow the casters to align with travel direction.

The script is customizable via two parameters:

  • WP_NUDGE_DIST: the “nudge” rollout distance (recommend 1-3 meters)
  • WP_NUDGE_VEL_D: the PSC_VEL_D value to use during a “nudge” (recommend 0.01 to 0.05)

rover-WPNudge.lua (6.6 KB)


Oh, so you think that the new branch is no more accurate than Rover-4.3.0-beta1?

I have seen improvements with a better WENC_POS_Y/WENC2_POS_Y adjustment. But I will have to compare:

  • Rover v4.2.3,
  • Rover v4.3.0-beta1,
  • your branch,
  • your branch with timing+rounding (five files),

on the same vehicle with the same mission and even repeat. Give me a couple of days (my feeling or preference is one of the last two).

1 Like

Since it was difficult to succeed reliably on the long lap mission as above, I decided a test of twelve eights around a square 1.2m x 1.2m, starting as before on virtual (40.1 -3.1) and returning to it (backwards), with two tests for each of above. Results follow.

Randy’s branch + IrqMod (five files substituted):





Randy’s branch:





Rover 4.3beta2 20221004:





Rover 4.2.3stable:





1 Like

Thanks @Webillo, so far it looks like the new branch and Rover-4.3.0-beta1 performance is pretty much identical.

At the time of this writing, Rover-4.3.0-beta1 flash and tests are pending (PIP takes a lot of computing time even on a M1), so no conclusion yet. Aditions will appear together above.

Performance shown by the Google Earth fingerprints is very similar, but that shows where the vehicle thinks it is: videos show where it really is, and there are differences (see video fingerprints). For example, mission end (when yellow trace retracts (on mission waypoint as home (also (40.1 -3.1)))) mostly appears east of home point with same latitude, but really it is south of it.

Completion at 20221007:

  • Randy’s branch+IrqMod: test1 GEfingerprint+video+VideoFingerprint, test2 GEfingerprint+video+VideoFingerprint (complete).
  • Randy’s branch: test3 GEfingerprint+video+VideoFingerprint, test4 GEfingerprint+video+VideoFingerprint (complete).
  • Rover-4.3.0-beta2 20221004: test5 GEfingerprint+video+VideoFingerprint, test6 GEfingerprint+video+VideoFingerprint (complete).
  • Rover-4.2.3stable: test7 GEfingerprint+video+VideoFingerprint, test8 GEfingerprint+video+VideoFingerprint (complete).
  • Other?: empty set ∅.


  • Trajectory followed better in v4.3betas than in v4.2.3stable, although difficult to differentiate fidelity in v4.3betas, both with Google Earth fingerprints and with video fingerprints (program quality different).
  • Vehicle completely silent in v4.2.3stable, but with tilt oscillations that cause great teeth noise in v4.3betas, so unless a better tuning is possible (how?) it seems difficult to justify the change, since v4.2.3 is sufficiently precise.
  • All versions with occasional communication failures, even with balance bot, ground station and router in the same room (wifi is used).
  • Message AP_Logger: stuck thread (write) at the beginning with v4.2.3stable; however, bin logs appear normally.
1 Like