Esa,
An interesting log because there are a number of unusual things happening so I’m just going to list them as a starting point:
-
the vehicle is travelling very slowly (as you’ve mentioned in previous posts). I suspect that 20cm/s is near (or perhaps below) the level of noise we get at least with most GPSs. I wonder if using wheel encoders would help improve the EKF’s speed estimates.
-
the GPS ground speed is odd. It is very often stuck at zero.
-
GPS2 is enabled but GPS1 is not. I don’t know of any problems when the 2nd GPS is used but it’s unusual.
-
From the plot of THR.DesSpeed vs THR.Speed graph you’ve posted above, the green line (THR.Speed) shows the actual speed estimate is going negative so the code thinks the vehicle is backing up and this could definitely lead to the vehicle travelling too far forward. There are at least three possible causes:
- the EKF’s speed estimate is incorrect perhaps because of the odd GPS data and/or because the vehicle’s turn is causing some kind of problem.
- in our throttle/speed controller only uses the forward-back component of the velocity vector. Older versions of Rover uses the full velocity vector regardless of which way it was pointing… that was clearly incorrect but I have had some worries that only using the forward-back component is too strict.
- the mounting of the flight controller is leading to velocity estimate errors when turning. The flight controller should ideally be mounted at the point on the vehicle that doesn’t move when the vehicle does a pivot turn.
-
the throttle/speed PID values are so low that they’re really not doing anything, the speed is almost entirely being controlled by the hidden feed-forward which is calculated from the cruise-throttle and cruise-speed values. Graphing the PIDA.P, I, D values you’ll see the D value is far larger than the P value but if you look at the THR.ThrOut value isn’t moving around much. From this you can see that the PID values are not contributing to the final output.
I think a couple of good tests to do would be:
- rotate the vehicle on the spot and see how the EKF’s velocity estimates (NKF1.VN and NKF1.VE) and THR.Speed values react. Probably best to test turning in both directions.
- perform a straight line waypoint and see how the above two values react as the vehicle stops
- drive the vehicle in Manual mode and see how quickly it stops. I suspect the issues you’re seeing are different from @Fellowhawk but doing this will separate whether it’s a motor-driver issue or an ArduPilot throttle control issue.