I am having problems tuning turn rate on small skid-steer rover with Pixhawk1 as controller. It keeps oscillating when stationary but when moving or turning on command in acro mode - it behaves reasonably well. It drives straight without yaw input and turns OK too. I tried setting FF to 0 or minimal value without improvement. Setting P and I to 0 resolves oscillation but if I change it even to 0.0001 - it starts doing it again. Currently I have P=0.2, I=0.1,D=0,FF=0.35.
On tuning chart piddesired is 0 and pidarchived changes between -50 and 50 when rover is supposed to be standing still. Compass is calibrated and stable, rover drives fine in manual and acro (just does not stand still in acro).
can you configure the ESCs on your rover to have a deadzone?
ESCs that I have do not have this feature. The signal that FC gives is well in usable range for throttle, so I would not want to throw it away.
I had this problem with a few of my rovers, too. It is mostly affecting skid steering rovers. I used a combination of setting a deadzone in the ESC and setting MOT_THR_MIN accordingly. You could try to set MOT_THR_MIN to 1 or 2% and see if it helps. This will cause ardurover to send out a throttle signal only if it is above the MOT_THR_MIN value. So the ESCs /motors may start faster than before. Test this with the wheels of the ground to protect the drivetrain.
Maybe post an onboard log if you have one.
I wonder if perhaps the autopilot is not in the middle of the vehicle or more accurately not near the point of rotation. Perhaps the rotation of the vehicle leads to a the autopilot sensing an acceleration or rotation that it then tries to fight against by rotating the vehicle the other way.
Originally I followed guide about setting minimum throttle and set MOT_THR_MIN to 15% as at that throttle all 4 motors were moving. After reading your post I decided to lower that value to see if deadzone will fix this oscillation - and indeed when I set MOT_THR_MIN to 0 the problem went away. Hopefully no other issues will arise with this setting but rover seems to drive OK for now.
Hey @andreyz and @rmackay9 ,
Maybe i had solved the same problem you mentioned a few weeks ago.
I was literally one second away asking the same question to @rmackay9.
First of all, little background-info about my project:
- two-chain wheeled Skid-Steer tracked vehicle as a base
- black cube with here2 gps as motion controller (Rover 4.2dev)
- jetson nano as companion computer with ROS Melodic on Linux
- ZED cam and hokuyo lidar as sensor input for mavros
- Mission Planner on Windows as GCS via WLAN connection
In Manual Mode the vehicle drive perfect. When i changed it to Arco-Mode/Steering-Mode the oscillation occurs. The standard parameter of the PID were useless in my case. I changed MOT_THR_MIN to 0% and the deadzone leaves a wobble free vehicle but you can hear the motor is still powering on minimum without movement. My solution was checking the position estimation is good (robot_localization pkg as sensor fusion with IMU, lidar-icp and odometry from ZED camera calculation). My mistake was, when i change MOT_THR_MIN or any of the other MOT params i have to do the cruise learing again (~0.5 cruise speed at 21 throttle)!
The oscillation in forward and backward direction is gone, the PID in steering is still 0 (P:0 I:0 D:0 IMAX:1 FF:0.5) as the tutorial video from @rmackay9 says.
With this configuration i can set the throttle PID accordingly to my wheeled base. (in my case: P:0,01 I:0,5 D:0 FF:0(because of cruise learning) and acro turning rate to 30.
When you have similar configuration, pls check the correct local position inside EK3 with vision position and check the cruise learning.
i hope this could help you.
EDIT: Randy marked the ATC_STOP_SPEED which has no effect in my case even when i set it to 0. Also i missed the SERVO_MIN and MAX parameter, they should be set accordingly to the real ESC MIN and MAX PWM drivable.
OK, thanks for the feedback and good to hear that the issue is resolved.
The ATC_STOP_SPEED is set to 0.1 (the default) of course? If it had been changed to something lower (including zero) then I can imagine that the vehicle never thinks it has stopped and would keep trying to control its speed.
… or if the previous MOT_THR_MIN value caused the vehicle to move at more than 0.1m/s then again I can imagine this problem could happen.
We could change the advice on the wiki to tell people to set the MOT_THR_MIN to the value just below the value that causes the vehicle wheels to move.