Incorrect Xbox controller motor mixing in QGroundControl and Cockpit

Hi everyone,

I am having an issue with the Xbox controller configuration and motor mixing on my BlueBoat.

When I test the motors using the Xbox controller in QGroundControl, only one motor responds:

  • Moving the right joystick horizontally controls only one motor. Moving the joystick left makes this motor rotate in one direction, and moving it right makes the same motor rotate in the opposite direction.

  • The second motor does not respond at all.

  • Moving the left joystick vertically, which should make the boat move forward or backward in a straight line, does not activate either motor.

I also tried changing the vehicle frame between Boat and Rover in QGroundControl, but this does not change the behaviour.

However, when I test the controller in Cockpit, both motors are working, but the controls are not mixed correctly:

  • Moving the left joystick vertically controls only one motor.

  • Moving the right joystick horizontally controls only the other motor.

Therefore, each joystick seems to control one motor independently instead of combining both motors for forward/backward movement and differential steering.

Could this issue be related to the joystick mapping, motor output assignments, frame configuration, or the ArduRover motor mixing parameters? Which parameters or settings should I check to configure the BlueBoat correctly?

Thank you for your help.

Hi @Ellio -

That is quite strange - I expected one motor to not be connected based on the initial symptoms, but them both working in Cockpit disproves that.

Can you:

  1. Load the default parameters for the BlueBoat from the Vehicle Setup / Configure page
  2. Share a screenshot of the table view of your Cockpit joystick configuration - are you using the desktop or lite version?
  3. Share what version of QGC you’re using - Blue Robotics has not tested past 4.2.8.
  4. Share a .BIN autopilot log found under Autopilot Logs in BlueOS, created by arming the vehicle for a period, and attempting to control the motors with the joysticks.

Thanks!

Hi @tony-white

Thanks for the response,

So I loaded the default parameters from the configure page but I had a window saying that the parameters in the group are already set to the desired values.

Then here is my screenshot from cockpit, I am using the desktop version

I did some tests and the right motor only moves when assigned axis z and the left motor only when assigned axis y.

For QGC i use the 4.2.8 Version

And finally here is the .BIN file

00000022.BIN (6.8 MB)

Hope this can help, I you need any other informations feel free to tell me !

This shows that your right and left motor outputs are misconfigured as Throttle and GroundSteering - like a boat with a single propulsion motor and a rudder for steering, than a skid-steering boat with two motors like the BlueBoat.

This should have been resolved by loading the BlueBoat’s recommended parameter set[1] as Tony suggested, but you can also fix it going to BlueOS’s Vehicle Setup / PWM Outputs page, and setting the Output 1 value (in the right side table) to ThrottleRight (74) and the Output 3 value to ThrottleLeft (73).

If there are remaining parameter issues I’d recommend re-loading the recommended parameters, or (if you haven’t done firmware configuration that you want to maintain) re-enabling the BlueOS setup wizard (via the cog button at the bottom of the left sidebar) to set things up properly for a BlueBoat.


  1. Note: this is not resetting to the ArduRover firmware defaults ↩︎

Hi @EliotBR

Thanks, that worked perfectly!

Just one small question: do you know what could be causing some latency with the Xbox controller signal? Sometimes the motors respond immediately, but other times there is a delay of around 0.5 to 1 second before they react.

Are there any issues reported in the BlueOS interface? Increased control latency is most likely an issue with either communication dropouts or the autopilot firmware being starved for processing power because of thermal throttling or other services/Extensions trying to do too much at once.

Hi @EliotBR,

After running several tests, I haven’t seen any issues reported by BlueOS. However, the latency seems to be quite inconsistent, and some control inputs occasionally get “stuck.”

For example, if I push the joystick forward and then return it to the center position, the motor sometimes continues turning as if the forward command is still active. To stop it, I have to briefly move the joystick backward.

here is the .bin if needed

00000027.BIN (3.1 MB)

Feel free to tell me where i can have a look or tests if it is more a communication or processing issues.

Thanks !

Hi @Ellio -

Have you tried with a different joysitck to rule out your hardware being the root cause?

If you update to the latest 1.19 Cockpit beta, there is a latency variable in the data lake. If you create a plotter widget, and select this variable, we can get an idea if the issue is related to your connection, or something else!

Hi @tony-white

Yes i have tried an other controller from an other brand but same issue.

I have plotted the latency, feel free to tell me if you have an idea from where the issue could come from !

Thanks !

Hi @Ellio -

That is some pretty terrible latency!

Can you install the tether diagnostic BlueOS extension and share a screen shot of its interface once loaded? This can be found in the extensions manager.

Can you share the results of the BlueOS network test?

I’d suspect your network connection to the vehicle is having serious issues…

Hi @tony-white

Thanks for the reply !

I’m still investigating and I’ve now run several tests.

The main symptom is a clearly visible delay between moving the Xbox controller joystick and the motors reacting. The delay can sometimes feel around 0.5–1 s or more.

I have downloaded the tether diagnostic but RX and TX are always both at 0 so I don’t know if I used it correctly or not.

Here are the tests I’ve done so far:

The BlueOS Local Network Test looks good.

RCIN vs RCOU

I downloaded the log and compared RCIN.C1 with RCOU.C1.

From what I can see, RCIN and RCOU react almost at the same time. I don’t see anything close to the physical 0.5–1 s delay between them.

This makes me think that once ArduPilot actually receives the control input, it processes it normally.

MANUAL_CONTROL vs SERVO_OUTPUT_RAW

I then plotted:

  • MANUAL_CONTROL.y

  • MANUAL_CONTROL.z

  • SERVO_OUTPUT_RAW.servo1_raw

  • SERVO_OUTPUT_RAW.servo3_raw

MANUAL_CONTROL reacts immediately when I move the joystick, while the servo output appears noticeably later.

I realise SERVO_OUTPUT_RAW is currently only being received at roughly 1.8 Hz, while MANUAL_CONTROL is around 13–14 Hz, so part of the apparent difference on the graph may be due to the telemetry update rate.

The same behaviour happens in both Cockpit and QGroundControl, so it does not seem specific to Cockpit.

Are there any specific logs that would be useful to check next?

Thanks!

Hi @Ellio -

Can you share what version of BlueOS you’re using?

Sharing a .BIN autopilot log where the problem occurs would be helpful. You can also download and share the BlueOS system logs, from the gear icon in the lower left of the BlueOS interface.

Are you using the Fathom-X tether interface to connect your vehicle to your computer? It’s very strange th tether diagnostic interface only shows zeros, can you share a screenshot illustrating this? How long is the tether you’re using?

Reading back to the top of the thread, if you’re using a BlueBoat then you almost certainly don’t have a tether, so the tether diagnostic extension won’t be helpful. I think this was an oversight in an internal support team meeting that Tony was sharing ideas from.

Indeed - it’s unlikely that once the autopilot has received the input enough to interpret it that there would be much delay before it responds, unless the hardware it’s running on is severely throttled.

Can you describe your network setup? Curious if that’s a standard BlueBoat setup with a BaseStation + wifi antennas, or if you’re operating via Cellular, Satellite, and/or a ZeroTier network.

There has also been a recent bug report about inefficient communication handling in the autopilot (with a proposed fix) which may be relevant here, though that’s somewhat dependent on whether you have additional sensors or peripherals connected that are integrated using MAVLink communication.

Hi @EliotBR

Yes I am currently working on a BlueBoat so It actually make sense that the tether diagnotic isn’t showing anything, I wasn’t sure.

About my network setup it’s the standard BlueBoat setup with BaseStation + wifi Antennas, and at the moment there is only a mR0 M8N GPS connected to the raspberry.

So would you think the fix from the bug report could be helpful ?

Thanks again !