Ardurover Balance Bot: EKF3 problems (yaw), mission impossible SOLVED!


I have assembled a balance bot with two DC motors with encoders on a pixhawk, driven by Barbie Harley Davidson. At present is is reasonably stable but slow, and it is impossible even to start a mission.

The goal is to do the same as a rover here on a real R/C car racing circuit, which with a RTK GPS can reasonable follow the track on the small circuit there 2m wide:

Here is a first 4K video (manually driven with the R/C transmitter):

As can be seen on the tlog part (in parallel with the view from a second camera doing a twitch transmission) it doesn’t know at all where it is and its orientation.

This is other simple test on the big circuit:

The small white horizontal lines are the starting grid positions (as in F1). The real trajectory was going from 7 to 3 forward, and back to 3 backwards, maintaining yaw (moreless north all the time). The yellow trajectory is what it thinks as the trajectory followed.

I’ve tried with v3.52 stable, v4.0.0 stable and v4.0.1 dev, and the yaw inconsistency always occurs. These situations are constant:

For analyzing what is happening with the yaw (and EKF3), I placed the vehicle still (constant coordinates) facing north (yaw 0) with the motors disconnected (no encoder signals) and armed it:

EKF Status Compass turns red, and it thinks the yaw changes slowly:

but even the gyroscopes are quiet:

This is the log, with actual configuration (v4.0.0 stable).

Is it normal that EKF3 behaves so? Can it be corrected? Configuration problem?
If this EKF3 behaviour is normal, what can be the problem for the attitude error which is making impossible even starting a mission?

1 Like

The video of the balance bot being driven manually looks quite good.

I suspect that the distances being reported from the wheel encoders are much too large and this is confusing the EKF. I haven’t looked at the logs yet though… but I will…

One thing to test would be whether the wheel-encoder distances seem correct or not. This should be visible using the mavlink inspector although it may only be possible to see the output from one wheel encoder at a time.

Hi. Thanks for watching.

About the great work by the developpers, some stability tests:

See also the Jumping Barbie on that video.

I’ll not be sure if everything is correct till everything works. However, note that on this test the encoders have no influence, since the motors are disconnected and don’t move. At most, something may complain because nothing moves.
In any case the relevant parameters are:

I’ll do some more static tests.

1 Like

Problems may be due to a deffective display which finally broke (it went black), which could mess with the RTK GPS external compass (even calibrations were succesful with two compasses, and no I2C errors seemed to appear). After substituting it, repeating the test with the Barbie with motors connected and armed, and not moving it, it stayed still during the several minutes test, and EKF compass indication was very low:


Pitch detail


WENC distances

So I’ll test mission again shortly. It seems that next sunday 19, satellites here won’t be favorable for RTK:

Yes, that happened. CPR’s should be 4x bigger. From motors description:

So it seems that CPR’s should be 9.6*11=105.6, but for whatever the reason they should be 4*9.6*11=422.4:

That also explains why here appeared rpm’s 4x with v3.52.

This is a single lap tlog capture:

This is the trajectory:

and these are the WENC distances:

Left wheel (inner) 129m
Right wheel (outer) 132m
From the 32 mission waypoints, applying the Haversine formula, lap length is 132.84m.

Mission (auto mode) didn’t work on the small circuit (perhaps high HDOP (as anticipated) and GPS shadowing), but a simple test on the big circuit beside, with much less GPS shadowing, was successful.

Some videos to come, wheather and HDOP permitting.

1 Like