Hi there,
I have the same Problem: Prearm check stops arming the vehicle because of “throttle not centered…” but is calibrated in win11 correct and works in QGC without issues.
Ardusub 4.8.0
BlueOS 1.4.3
Cockpit 1.18.2 Desktop
Logitech Gamecontroller F310
I tried to fix it with AI help but no solution until now. Any ideas?
Hi @schleitaucher -
You’re running a beta version of ArduSub, with a very old version of BlueOS! Give 1.4.5 stable BlueOS a try, and 4.7.0 Ardusub - or even 4.5.7. If you continue to have issues, please share a BlueOS system log file, found from the gear icon in the lower left of BlueOS.
Ardusub 4.7.0
BlueOS “latest” (?)
Cockpit 1.18.2 Desktop
Logitech Gamecontroller F310
Rasp Pi 4b
Pixhawk 1
I’m not sure if there is a difference between “latest” and stable 1.4.5?
For now nothing has changed. Cockpit denies arming the ROV and QGC is running without issues. I’m wondering why Cockpit tells me “unknown controller” in the joystick settings.
Regards
Chris
Hi @schleitaucher -
You definitely don’t want to be on “latest” BlueOS - please update to stable 1.4.5 - latest is similar to master, and does not contain stable software! Version 1.4.5 was recently released as stable and contains many fixed - it is what the 1.4.4 beta versions matured into!
However, this does sound like it may be an issue with Cockpit and ArduSub getting a bit tripped up. Assuming this is a BlueROV2, can you try loading the latest default parameters, just to see what would be changed or added? I’m wondering if it is a parameters issue… maybe @rafael.lehmkuhl has some ideas?
I have a vague recollection of QGC messing with some RC parameters as part of calibration at times… What’s your RC3_TRIM value (in the BlueOS Autopilot Parameters)? It should be set to 1500.
Beyond that, you can check what Cockpit is sending and the equivalent radio inputs the autopilot converts that to in Cockpit’s MAVLink Inspector (Tools / MAVLink in the sidebar), by monitoring the MANUAL_CONTROL and RC_CHANNELS messages, which should look like this when there’s no joystick axis deflection:
If MANUAL_CONTROL has a non-500 Z value then there’s a problem with what Cockpit’s outputting (which may be a Cockpit problem, or a joystick problem, though that seemed ok in your previous joystick configuration screenshot). If RC_CHANNELS channel 3 has a non-1500 value then you’ve got some throttle offset configured, which I believe is only possible via the “input hold” joystick button function, but that shouldn’t be persistent across autopilot reboots.
We’ve designed visual configuration interfaces for some controller types, but understandably we can’t cover every controller in existence. “Unknown” just means Cockpit doesn’t know about that controller type, which is either because we haven’t implemented it (in general), or because the identification method Cockpit uses to determine controller types doesn’t include your specific model (e.g. Microsoft keep changing the serial numbers for different XBox controllers, so new ones don’t get properly detected by Cockpit until we find out about them and add them to the list).
Cockpit can handle generic/unknown controllers by just providing a table of axis and button mappings, but it’s extra convenient when you can see your button assignments on a visual interface that corresponds to the controller in your hands 
Thanks a lot for the fast reply! The RC3_Trim is already set to 1500. I’ve changed blueOS again, now to 1.4.5 but nothing changes. Here you see the Mavlink screen:
I’m not sure if it has something to do with the permanent connection-heartbeat lost-disconnection-issue. To get that I have nothing else to do then connect the ROV2 and leave it in standby. After 10 oder 15 Minutes this issue seems to stop and it stays connected. Also I cannot get a Videostream with the web version of cockpit. It tells me something about another stream is selected but I cannot switch between Stream1 and the “phantom”.
I would go on using QGC instead of cockpit because it works but the latency of cockpit is much better than QGC. Since the first release of cockpit I wasn’t able to do only one mission with cockpit and spend hours configuring and upgrading to get it work. No success until now. Maybe we will find way together. Many thanks for your support!!
Ok, chan3_raw here is 1300 but should be 1500, so the autopilot at least thinks it’s receiving a non-neutral throttle (vertical) input.
Could you also take a screenshot of the MANUAL_CONTROL message in that same screen, so we can see whether it’s a problem with what Cockpit’s sending or if it’s an autopilot configuration issue?
@schleitaucher have you changed something in the joystick mapping from this screenshot (yesterday) and your last one? I ask because on rest Axis Z was supposed to be sending 500, not 0, the same way as this screenshot from Eliot. Your mapping from yesterday is correct with +1000 : 0 mapping on Z. Can you look at it now?
All I changed was the version of blueOS nothing else. The parameters are still on 1300 and 0 for chan3_raw and z axis. I changed today the windows-computer, now one with win 10 and cockpit 1.18.2 fresh installed without any changings, just installed and start. Interesting that the can3_raw parameter is correct at 1500 and the z axis parameter in the manual control window is at 500. That looks OK to me. But the problem persists, no arming possible because of throttle not centered…
edit: I also tried an Microsoft xbox controller instead of the logitech, no effect. When I reset the parameters after removing the controller, all is on 1500. In the moment of plug in the controller the chan3_raw changes from 1500 to 1300.
Update: I tried again the other topside computer and… it works. This Computer unfortunately is not useable for outdoor operations so I have to continue to find out whats wrong with my dell toughbook…
Edit: now I can reproduce the issue: When I switch in cockpit from an individual user to the standard fallback user, the problem is solved. Reproduceable on both topside computers.
Hello, looks like another user has identified this but our bluerovs are inoperable after upgrading to 1.4.5. The clockpit client 1.18.2 fails to arm with error.
PreArm: Throttle not centered/close to trim
In cockpit lite the controllers are not recognised at all.
Hi @Jono,
That warning comes from ArduSub, and is based on what Cockpit is sending it - the BlueOS version shouldn’t be relevant.
Can you share which ArduSub version you’re using, along with your configured joystick axis ranges (from Cockpit’s joystick page), and the RC_CHANNELS.chan3_raw and MANUAL_CONTROL.z MAVLink message values as requested above?
It could also be helpful to have a Cockpit system log (from Settings / Dev in the sidebar menu), and an autopilot DataFlash (.bin) log (from the BlueOS Log Browser). Also, are you using Cockpit Lite (in a browser), or the standalone Cockpit application on your computer?
Hey @EliotBR,
I found that when I’m setting Axis Z 0 to +1000 in ArduSub 4.5.7, it works fine, but when I update to 4.7.0, Axis Z 0 to +1000 results in the ROV throttling into one direction. Same Joystick settings, different ArduSub versions, different Axis Z Handling.
Ardusub 4.7.0 and todays new 4.7.1, the arming error is in the cockpit client 1.18.2. In cockpit lite the controllers are no longer recognised at all. Same xbox controllers in use for years, the system has windows updates disabled so should not have changed.
Edit to attach files, .bin is probably not fresh, needs to arm to generate a new one right?
Cockpit (Sep 04, 2026 - 12꞉49꞉32 GMT+12).syslog (37.2 KB)
00000365.BIN (388 KB)
Hi @Jono -
Did you push a button on your controller to get Cockpit to display it? It is expected that nothing shows in the interface until you do… It is strange that the ch3 output is not centered at 1500 given no controller is connected!
@Jono also could you attach a Cockpit syslog from the Lite version, where the joystick is not working for you? The one you attached is from Standalone, where the Xbox One controller is being recognized correctly.
Hi folks, we believe we’ve found the underlying issue here:
From here:
If you don’t want to wait:
inputs/mavlink/axis- data lake variables, and then remap your joystick axes to the desired functions things should work normallyConfirmed 1.18.3 solves the problem.
Cockpit lite was still affected with the controller acting like a mouse device, sticks moving the cursor, and buttons clicking visual elements insted of being interpreted as inputs in cockpit.
Solved after a windows update, the search for a way to disable micro$oft self-destruction that actually works continues..
Great - thanks for confirming!
Huh - haven’t heard of that one before. Looks like there’s a very recent Microsoft support thread about it.
Glad you managed to resolve the issue
Preventing a large business’s pathway certainly seems challenging, but perhaps you could minimise the personal impacts by using alternative products? It seems Linux is gaining a fair amount of traction as Windows marches itself away from consumer interests, and can be tried out from a USB stick or external hard drive (or installed on a disk partition) if you don’t want to wipe a (mostly 
) working system. MacOS is also an option, though that generally requires buying different hardware.