Runaway behavior with encoders

[John_Walthour]

I’m experiencing some issues while operating a rover in guided mode with a companion computer. When using wheel encoders, if the rover receives a speed target over about 1m/s, the rover increases throttle apparently without limit, until disarmed. Confusingly, this problematic behavior goes away if I disconnect the encoders from the autopilot.

The rover is a custom build, with the following setup:

• CubePilot Orange autopilot
• Two tank treads, each driven by a GoBilda “Yellow Jacket” motor with a built-in encoder.
• A companion computer, connected to the USB port on the autopilot, for control in Guided mode
• A Futaba RC receiver connected to the RC IN port on the autopilot, for control in Manual mode.
• A telemetry radio connection to a laptop, so I can monitor everything in Mission Planner.
• A playstation controller hooked up to in-house-developed software on the companion computer. Software reads the playstation stick values, then sends SET_POSITION_TARGET_LOCAL_NED commands in the MAV_FRAME_BODY_OFFSET_NED frame with target X velocity and target yaw rate.

My intent is to operate this rover just based on dead-reckoning, and have no reliance at all on GPS. Since I wanted to rule out GPS instability as a possible issue, I unplugged the GPS receiver entirely.

I followed the directions on this page: Wheel Encoders — Rover documentation (If you see any discrepancy between the directions on this page and the attached parameters file, please let me know.)

I’ve been conducting the following tests with the rover up on blocks on my desk. I figure the EKF should be getting its speed solution from the motor encoders, so the IMU shouldn’t have to actually move in order to get some reasonable behavior. The last time I put it on the ground for this test, the rover ran off at high speed and slammed into my office wall. So I’m really hoping to be able to confirm that this behavior is fixed before letting it roam free.

When I set the autopilot into “manual” mode, the rover can be operated with the RC controller, and behaves as expected. Driving the stick forward moves the rover forward. Wheel distances, as viewed in Mavlink Inspector, move as expected. When the rover goes forward, the left wheel distance reports values that become more and more negative, while the right wheel distance becomes more and more positive. (This is consistent with the screenshot on the wheel encoders page, but if this is backwards, please let me know). The ground speed reported in Mission Planner does something a little strange: it flips between 0.0 m/s, and some sane speed that appears to match the speed of the treads.

I then set the autopilot into “guided” mode. I tell our software to command a velocity target using the SET_POSITION_TARGET_LOCAL_NED, masked to command a target X veocity and a target yaw rate, in the frame MAV_FRAME_BODY_OFFSET_NED. If the encoders are disconnected, this commands movement of the chassis in exactly the desired manner - forward X values cause the rover to move both treads the same way, etc. However, if the encoders are connected, when the target speed goes above some threshold, it seems like the rover enters some sort of positive feedback cycle, and it accelerates, seemingly without bound.

Can anyone spot an issue here?

2024-02-22 rover 1 at time of log.param (16.3 KB)

I’ll try to get the log uploaded to a sharing service and comment with it.

[stephendade (Stephen)]

@John_Walthour

I figure the EKF should be getting its speed solution from the motor encoders, so the IMU shouldn’t have to actually move in order to get some reasonable behavior

The EKF uses a fused Wheel Encoder + IMU for velocity. So both need to be “moving”, otherwise the EKF will get very confused.

@John_Walthour

When the rover goes forward, the left wheel distance reports values that become more and more negative, while the right wheel distance becomes more and more positive. (This is consistent with the screenshot on the wheel encoders page, but if this is backwards, please let me know)

This is not correct. If the vehicle is moving forwards, both wheel encoders need to be increasing in value.

[John_Walthour]

Thanks Stephen, that’s very helpful. I’ll try to find a safe way to test this with the rover actually moving.

Do you have insight into how the rover computes heading when it has wheel encoders? Like if the right tread goes forward by π * rover_width, and the left tread goes backward by the same amount, will the heading change by 180°? Or does it rely on the IMU for yaw information?

[John_Walthour]

Here is the log if it makes any difference: 1 1979-12-31 19-00-00.bin - Google Drive

[stephendade (Stephen)]

@John_Walthour

Do you have insight into how the rover computes heading when it has wheel encoders? Like if the right tread goes forward by π * rover_width, and the left tread goes backward by the same amount, will the heading change by 180°? Or does it rely on the IMU for yaw information?

Wheel encoders are purely used for (3D) velocity calculations.

Yaw is separate, because you need an absolute heading. See EKF Source Selection and Switching — Copter documentation for more details.

I had a quick look at your EK3_SRC1_* params. Some of them are 0, which isn’t good. Each source does need to be specified - A value of 0 means the IMU is not fusing with an external source, which will rapidly lead to drift and a very unstable orientation/location solution. “Rapid” for rovers being ~1min, but far less (seconds) for copters.

[Webillo]

@John_Walthour

I’ll try to find a safe way to test this

Simply, arm and move the vehicle forward in a straight line some distance, as 10m. From the log, MP should show both WENC distances positive and increasing 10m exactly, with which you can check pin assignments, CPR’s and radios.

If rotating the vehicle, the forward encoder should go positive, and the other negative.

[John_Walthour]

Thanks Stephen, that’s helpful, and that link was informative.

Each source does need to be specified

That might explain what I’m seeing. I found this page: GPS / Non-GPS Transitions — Copter documentation The youtube video seems to show the situation I want - the rover falls back to encoders when it has no GPS fix. Unfortunately that page doesn’t describe the configuration used in the youtube video, and the classic “Wheel encoders” page says to set EK3_SRC1_POSXY = 0, which is why I set it that way.

Are you saying that no source should have any zeros? In which case I should have something like:

• EK3_SRC1_POSXY = 3 (GPS)
• EK3_SRC1_VELXY = 7 (Wheel encoders)

Or are you saying the primary source really shouldn’t have any zeros, but it’s OK for a secondary source to? In which case maybe:

• EK3_SRC1_POSXY = 3 (GPS)
• EK3_SRC1_VELXY = 3 (GPS)
• EK3_SRC2_POSXY = 0 (None but that’s OK because the primary source has one?)
• EK3_SRC2_VELXY = 7 (Wheel encoders)

This is probably showing my ignorance of the details of how the EKF is structured.

[John_Walthour]

Thanks Webillo! Next time I have access to the rover I’ll make sure to test that the CPR is set correctly. I could see that messing with the IMU if the encoders report a speed that’s never consistent with the accelerometers.

[stephendade (Stephen)]

@John_Walthour

classic “Wheel encoders” page says to set EK3_SRC1_POSXY = 0, which is why I set it that way.

Ahh, my bad. That should be fine then.

[John_Walthour]

I figured it out.

I realized that the runaway behavior was actually occurred in the reverse of the direction that I expected. The autopilot must have been trying to meet the velocity goal by making the motors push the rover in the +X direction, then it moved in the -X direction, resulting in a positive feedback cycle.

Reversing the direction of motor output did the trick. (obviously I could also have switched the motor wiring) I would speculate, but have not confirmed, that the rover’s behavior is now much less sensitive to misconfigurations in the EKF. I’m not positive that I have the EKF optiminally configured, but the rover no longer runs off into the wall.