Context:
Hi all, I’ve been working on a 4WD skid steer rover over the winter and have finally gotten everything to the point where autonomous navigation should be possible. After burning a bunch of time trying to skip straight to the fun part (the rover drove properly in both acro and steering modes, but was behaving unpredictably in auto mode), I decided to follow the manual and try to clean up the PID tune. Starting with the cruise speed learning: I ended up having to bypass this and set the values manually as the autolearn would fail every time it was attempted.
The problem:
The problem I’m currently dealing with is that piddesired does not seem to be tracking the correct PID controller. With GCS_PID_MASK set to 1 for steering, piddesired only changes when commanding a forward/reverse, and pidachieved only changes when commanding a pivot left/right. It seems that the piddesired data is coming from the speed control PID, while pidachieved is coming from the steering control PID. Is this the expected behavior with a skid steer vehicle? Should I monitor a different set of parameters for the tuning?
The system:
Holybro Pixhawk 6X v1
4x wheelchair brushless motors, each driven by an ODrive S1
Holybro UM982 moving baseline GPS
simpleRTK2B RTK base receiver w/survey antenna
RFD900x telemetry radio pair
TX16S w/Spektrum serial receiver for RC
…and an assortment of linear actuators, spotlights, relays, and buck converters for auxiliary functions
Ardurover v4.5.7 config attached. Using MP v1.3.82 as GCS. 3-14_rover_cfg.param (16.2 KB)
Additionally, the UM982 is a dual-antenna design, and the distance between the two antennas should be greater than 30 cm. The GPS_POS2 parameters do not need to be set.
@Derek_Wen Just tracked this down to a servo reversal issue in the process of testing things to respond to this, so thanks for the assistance! Also, good catch with the GPS_POS2 parameter, that was from some earlier testing I did which I forgot to revert. The GPS heading and position shown in Mission Planner were stable and correct either way, so I don’t believe that particular parameter actually does anything with this configuration.
For future reference, the following is a good field test to determine if servo reverse parameters are correct on a skid-steer vehicle. You can also use the Motor Test panel in Mission Planner if the wheels are removed or raised off the ground (Ref. Rover wants to reverse, even when waypoint is straight ahead - #9 by Yuri_Rage):
Set WP_PIVOT_ANGLE to 30 degrees.
Configure a mission with a single waypoint far away from the rover on a visible landmark.
Repeat the mission, starting the rover with a different initial heading each time.
If you have a right servo reversal issue, you will likely see the following behavior:
If the rover’s heading is within ~30 degrees of the waypoint, turn ~180 degrees and start moving away from the waypoint.
If the rover’s heading >30 degrees off clockwise from the waypoint, go straight reverse indefinitely.
If the rover’s heading is >30 degrees off anti-clockwise from the waypoint, go straight forward indefinitely.
If you have a left servo reversal issue, you will likely see the following behavior:
If the rover’s heading is within ~30 degrees of the waypoint, turn ~180 degrees and start moving away from the waypoint.
If the rover’s heading >30 degrees off clockwise from the waypoint, go straight forward indefinitely.
If the rover’s heading is >30 degrees off anti-clockwise from the waypoint, go straight reverse indefinitely.
Could this behavior of the machine be caused by a heading issue? Also, I noticed that you are using an RTK base station. Did the rover obtain RTK Fixed?