Using latest beta version on Pixhawk 2.1 with Here+ RTK, Sabertooth 2 x 25. Servo function rc1 = 73 servo function rc3=74. In manual mode, it will have crisp left and right turning that stops immediately when releasing joystick to center. In throttle forward or reverse, it seems to slowly build up to max speed but does not have any braking and will continue to roll past intended target. Any ideas on how to make the throttle response as responsive as turning? I’ve played with transmitter exponential and linear responses and no change in throttle responsiveness. Thanks!
Dustin,
You’ve probably already seen the Tuning Speed and Throttle wiki page but here’s the link just in case.
Is the vehicle in Manual mode or is it another mode? In which case the only thing in ardupilot that could affect this is the MOT_SLEWRATE parameter (it’s mentioned at the bottom of the above linked tuning page). So you could try setting that to zero to disable the throttle slew feature. I suspect though that what you’re seeing is a feature of the motor driver itself.
If you’re not in Manual mode then it’s probably best to provide a log. It may be the ATC_ACCEL can be increased or ATC_BRAKING can be enabled to help.
Thanks for your help! And yes, everything is in manual mode. I will take a look and check the parameters tomorrow.
Hi @rmackay9 / @Fellowhawk ,
I think i’m seeing a similar problem in guided mode !
I have a simple square path that I’m currently trying to tune the robot on.
At every waypoint it overshoots by about a metre. I am currently running the robot in guided mode (I’m sending throttle and turn rates to the ardurover software via mavros).
here is a plot of the THR Des Speed vs THR Speed
Des Turn rate vs Turn Rate
As you can see at every turn (waypoint 2 ,3 & 4 ) (see the big green dips in the throttle graph) we command the rover to stop before issuing a turn rate …but the robot keeps moving.
Logs can be found here - waypoint overrun log 144
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.
Hi @rmackay9,
Thanks for the feedback. I will do those test - hopefully on Monday/Tuesday.
The reason why I resorted to only using GPS 2 (My Emlid Reach RTK is connected to this) was because during my tests, I kept getting errors saying that the location of GPS 1 (onboard Navio 2 gps) vs GPS 2 was different by XX metres. I just decided that I can make do with just 1 really accurate GPS.
Currently the flight controller is mounted in the centre of the platform. I’m currently working on version 2 of the platform and the flight controller is mounted to one side of the platform. Will this be a huge problem for me in the future ? Can’t I simply put in an offset?
Esa
Esa,
Placing the flight controller in the middle (or more accurately at the point on the vehicle that it rotates around) is best but you can try the offset method described on the “Sensor Position Offset Compensation” wiki page. It compensates somewhat but not fully I think. I haven’t seen enough people making use of the feature to know how well it works in practice. I guess we will find out when you try it! 