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

[Webillo]

Hi.

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:
Video
Video
Video
Video
Video
Video
Video

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?

[rmackay9]

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.

[Webillo]

Hi. Thanks for watching.

@rmackay9

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

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

20200116 ArduRover v4.0.0 Balance Bot stability tests experimental experiment

See also the Jumping Barbie on that video.

@rmackay9

I suspect that the distances being reported from the wheel encoders are much too large and this is confusing the EKF

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:
WENC_CPR,105
WENC_PINA,53
WENC_PINB,52
WENC_POS_X,0
WENC_POS_Y,-0.065
WENC_POS_Z,-0.03
WENC_RADIUS,0.034
WENC_TYPE,1
WENC2_CPR,105
WENC2_PINA,54
WENC2_PINB,55
WENC2_POS_X,0
WENC2_POS_Y,0.065
WENC2_POS_Z,-0.03
WENC2_RADIUS,0.034
WENC2_TYPE,1

@rmackay9

This should be visible using the mavlink inspector

I’ll do some more static tests.

[Webillo]

@Webillo

I’ll do some more static tests.

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

Pitch detail

Yaw

WENC distances

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

[Webillo]

@rmackay9

I suspect that the distances being reported from the wheel encoders are much too large and this is confusing the EKF.

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:
WENC_CPR,422
WENC2_CPR,422

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

This is a single lap tlog capture:

ArduRover 20200119 Barbie-12 Asoger 1/18 single lap acro experimental experiment

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.