[Bug] Rover Differential - Doesn't turn in Mission Mode (v1.17 Stable)

[DanieleAzz]

Describe the bug

Hi there,

I've built a differential rover and flashed a custom 'rover.px4board' target for it. After the initial configuration, I am unable to get it to navigate successfully in Mission mode.

Actual Behavior:

The rover moves back and forth, trying to reach the first waypoint without success. It looks like it tries to make a turn, fails to do so, and ends up driving back and forth over the same spot.

Expected Behavior:

The rover should calculate the heading to the waypoint, turn, and drive straight to it, similar to how it behaves in SITL.

Troubleshooting & Context

• Manual/RC Modes: In Manual, Stabilized, and Position modes, the rover drives forward and turns perfectly following RC commands (I just need to fine-tune the PID). Note: I noticed it doesn't turn at full throttle, likely because there is no motor headroom left to distribute power for differential steering.
• ROS 2 Custom Mode: Following the documentation, the rover turns perfectly when using RoverSpeedSteeringSetpointType. However, it fails to turn using RoverPositionSetpointType. I wrote a script to simulate a GoTo mode (reading 9 GPS coordinates, translating to NED, and sending them via position_setpoint_->update()), and it exhibits the same back-and-forth behavior as Mission mode.
• SITL: Running make px4_sitl gz_rover_differential, every test I’ve made using ROS2 Custom mode works perfectly. The issue only happens on real hardware.

Because it works in SITL and manual modes, my guess is that there is an issue with the position controller, or I have a misconfigured parameter causing the rover to fail its navigation loop.

Thank you for your help!

Flight Log / Additional Information

This is my Hardware configuration:

• Frame: Lynxmotion A4WD3
• Motor Controller: Sabertooth 2x12
• Flight Controller: Cubepilot Orange Plus
• Carrier Board: Airbot mini carrier board PRO v2
• GPS: Here4
• Companion Computer: RPi 5

Software & Firmware Details

PX4 Version: v1.17 Stable (Branch: release/1.17)
Custom Board Target: rover.px4board (I would love to contribute this back! 😄)
rover.px4board build flags:

CONFIG_MODULES_AIRSPEED_SELECTOR=n
CONFIG_MODULES_FLIGHT_MODE_MANAGER=n
CONFIG_MODULES_FW_ATT_CONTROL=n
CONFIG_MODULES_FW_AUTOTUNE_ATTITUDE_CONTROL=n
CONFIG_MODULES_FW_MODE_MANAGER=n
CONFIG_MODULES_FW_LATERAL_LONGITUDINAL_CONTROL=n
CONFIG_MODULES_FW_RATE_CONTROL=n
CONFIG_MODULES_MC_ATT_CONTROL=n
CONFIG_MODULES_MC_AUTOTUNE_ATTITUDE_CONTROL=n
CONFIG_MODULES_MC_HOVER_THRUST_ESTIMATOR=n
CONFIG_MODULES_MC_POS_CONTROL=n
CONFIG_MODULES_MC_RATE_CONTROL=n
CONFIG_MODULES_VTOL_ATT_CONTROL=n
CONFIG_DRIVERS_ROBOCLAW=y
CONFIG_MODULES_ROVER_ACKERMANN=y
CONFIG_MODULES_ROVER_DIFFERENTIAL=y
CONFIG_MODULES_ROVER_MECANUM=y

Mavlink Shell Output

nsh> ver all
HW arch: CUBEPILOT_CUBEORANGEPLUS
PX4 git-hash: 812b0fbca6bfa32f475e93cc521978df333e2cd0
PX4 version: 1.17.0 0 (17891328)
PX4 git-branch: release/1.17
OS: NuttX
OS version: Release 11.0.0 (184549631)
OS git-hash: fb2fadf6f599c1406f052db013efd00a2518e72c
Build datetime: May 27 2026 12:51:44
Build uri: localhost
Build variant: rover
Toolchain: GNU GCC, 10.2.1 20201103 (release)
PX4GUID: 000600000000373434333233510d00290022
MCU: STM32H7[4|5]xxx, rev. V

Flight Logs

• Test 1 (Position/GoTo Mode): Flight Review Log
  • Behavior: Outside using the Custom mode called "ROS2 Go To". The rover moves very slowly back and forth. You can see it trying hard to turn but failing.
• Test 2 (Speed/Steering Mode): Flight Review Log
  • Behavior: Outside using the Custom mode called "ROS 2 Circle". The rover acts as expected, driving a circle until it hit an object and almost flipped (hence the high vibrations).

Code Snippets

• Test 1 (Position/GoTo Mode):

static const std::string kName = "ROS2 Go To";

class MyGotoMode : public px4_ros2::ModeBase
{
public:
    MyGotoMode(rclcpp::Node& node) : ModeBase(node, kName) {
        position_setpoint_ = std::make_shared<px4_ros2::RoverPositionSetpointType>(*this);
    };

    void onActivate() override { 
        active_ = true; 
        RCLCPP_INFO(node().get_logger(), "==> 'ROS 2 Go To' Mode Activated via QGC!");
    }

    void onDeactivate() override { 
        active_ = false; 
        RCLCPP_INFO(node().get_logger(), "==> 'ROS 2 Go To' Mode Deactivated!");
    }

    bool isActive() const { 
        return active_; 
    }

    void updatePosition(float x, float y){
        // Pack x North and Y East in meters into a Eigen 2D vector:
        Eigen::Vector2f target_position_ned(x,y);

        float cruising_speed = .5;
        
        // Update the position setpoint with it
        position_setpoint_->update(target_position_ned, std::nullopt, cruising_speed);
    }

private:
    bool active_ = false;
    std::shared_ptr<px4_ros2::RoverPositionSetpointType> position_setpoint_;
};

• Test 2 (Speed/Steering Mode):

static const std::string kName = "ROS 2 Circle";

class MyCircleMode : public px4_ros2::ModeBase
{
public:
    MyCircleMode(rclcpp::Node& node) : ModeBase(node, kName) {
        steering_setpoint_ = std::make_shared<px4_ros2::RoverSpeedSteeringSetpointType>(*this);
    };

    void onActivate() override { 
        active_ = true; 
        RCLCPP_INFO(node().get_logger(), "==> 'ROS 2 Circle' Mode Activated via QGC!");
    }

    void onDeactivate() override { 
        active_ = false; 
        RCLCPP_INFO(node().get_logger(), "==> 'ROS 2 Circle' Mode Deactivated!");
    }

    bool isActive() const { return active_; }

    void updateVelocity(float speed, float steering){
        steering_setpoint_->update(speed, steering);
    }

private:
    bool active_ = false;
    std::shared_ptr<px4_ros2::RoverSpeedSteeringSetpointType> steering_setpoint_;
};

[SofianElmotiem]

Hi, I had a look at the rover differential code and I think I can explain what's happening.

Root cause

In auto/mission mode the control chain is: position controller → attitude controller → rate controller → actuators. When the rover needs to spot-turn, the rate controller computes the motor differential using a feedforward formula:

speed_diff_normalized = (yaw_rate_setpoint * RD_WHEEL_TRACK / 2) * RO_YAW_RATE_CORR / RO_MAX_THR_SPEED
If RO_MAX_THR_SPEED is set too high (e.g. from SITL defaults, which can be 3–5 m/s), the normalized output becomes tiny. For a 1 rad/s yaw rate with 0.4 m wheel track and RO_MAX_THR_SPEED = 3.0, the steering command is ~6.7%. A real Sabertooth motor controller with any dead-band or friction won't respond to that. In SITL the model responds to any nonzero command, which is why it works there.

In manual mode you're sending roll stick → steering directly as a normalized [-1, 1] value, completely bypassing this feedforward chain. That's why manual works fine.

The "back and forth" motion is a consequence: the rover enters SPOT_TURNING (speed = 0), the tiny steering command fails to turn it, GPS drift momentarily lowers the apparent heading error, it briefly switches back to DRIVING, moves forward in the wrong direction, heading error grows again, back to SPOT_TURNING. Repeat.

Parameters to fix first wihth no firmware rebuild needed

*RD_WHEEL_TRACK: set to the actual center-to-center wheel distance in meters. Default is 0, which disables feedforward entirely.
*RO_MAX_THR_SPEED: drive the rover at full throttle in manual mode, measure the actual top speed in m/s, and set this to that value. This is probably the biggest lever.
*RO_YAW_RATE_I: default is 0. Set it to something like 0.1–0.3 so the integrator can overcome motor dead-bands.
*RO_YAW_RATE_CORR: try 2.0–4.0. The description specifically mentions this is useful for skid-steer rovers with friction when turning in place.
Potential code issue

There is also a minor bug in DifferentialRateControl::updateRateControl() where RO_YAW_RATE_TH (described as a measurement noise threshold) is applieed to the yaw rate setpoint as well:

const float yaw_rate_setpoint = fabsf(_yaw_rate_setpoint) > _param_ro_yaw_rate_th.get() * M_DEG_TO_RAD_F ?
_yaw_rate_setpoint : 0.f;
This creates a dead-band in the closed-loop position control: small turning commands near the SPOT_TURNING/DRIVING state transition get zeroed out, contributing to the oscillation. The threshold makes sense for the measured yaw rate (to suppress noise when stationary), but not for the setpoint. Removing it from the setpoint would be a clean fix.

[dirksavage88]

@DanieleAzz I took a look at the log, the only thing I can think of is the RO and RD params.

1. RD_TRANS_DRV_TRN: are you able to manually steer and spot turn without issue in acro, stabilized, and position modes? I only see an external mode in the logs.
2. RO_YAW* and RO_YAW_RATE* set correctly, per the PX4 User guide
3. Make sure the mag on the here4 is calibrated correctly and shows accurate heading
4. Try an actual mission waypoint plan set up in QGC, and not the offboard/external code. Then we can take a look and see if it is something specific to the offboard code or if it is the rover position controller that is the issue.

[DanieleAzz]

@dirksavage88 Thank you for your help!

1. I am able to steer and spot turning in all the modes you mentioned: acro, stabilized, position, and also manual. The only thing is that if I am going full throttle with the RC, I cannot make turns. But, if I lower the throttle, I am able to steer while driving forward
2. It looks like they are set correctly
3. The mag for the Here4 is calibrated and shows the right heading
4. I created a mission, and here is the log file:PX4 Flight Review

Mission Description:

Mission mode and arm. Then the rover moved straight and reached the first 2 waypoints (the waypoints were in front of it), then it struggled to reach the next waypoint. I waited a little bit, but nothing happened - it did not move, so I tried to do a right click on QGC and do "Go To this location", so the rover turned and drove towards that location, but before reaching it, it stopped. Then I waited... nothing, so I decided to resume the mission, and the rover started to drive in a completely wrong direction.

Thanks again!

[dirksavage88]

@DanieleAzz could you try setting the following:

RD_TRANS_DRV_TRN = 0.087

You can also compare your params to what I have here: https://review.px4.io/plot_app?log=a24ca34d-ad18-4e95-a729-e2f19d022de9. This rover is the GoBILDA kit btw

In that log I had planned mission waypoints with 90 degree turns, but am curious as to if you are setting mission/offboard waypoints with <90 degree turns and maybe the yaw error threshold to trigger from driving to spot turning is too high or being ignored.

The other thing I would try is driving on grass. This is just to rule out compass interference with rebar reinforced concrete.