Joysticks issue, using Cockpit


Hi Rafael, I have uploaded the requested screenshot. Looks very similar to yours regarding the axis.
The other strange behaviour where each time you arm, disarm, and re-arm, the vertical thrusters will spin faster. Like there is some value-addition going on, and is being remembered from one “arm” session to the next.

Thanks again for your help.

Was the screenshot taken with the vehicle armed and the thrusters spinning?
If so, this would be ultra strange.


Hi Rafael, The latest is with the vehicle armed. 4 vertical thrusters spinning.(slowly)

@UnderseaROV me and @tony-white have some better clues on what’s happening now.

Could you get us a .BIN log from the vehicle, from a session where those problems are happening? You can get download them on BlueOS.

@williangalvani we think you should also take a look at this. We believe the problem could be in the firmware. The difference between Cockpit and QGC is that we send the S and T axes, while QGC does not.

  • It looks like the S and T axes aren’t being scaled (which is a bug)
  • Because the roll-pitch toggle option still exists, if that’s active then there are multiple axes adding together to control the same functionality, which could constructively interfere to have out of range values
  • But if S and T are zero, as far as I can tell the behaviour would be identical to if they’re not provided, so that still doesn’t necessarily explain the issue :person_shrugging:

If it’s firmware-related, hopefully @williangalvani can find some other insights. Otherwise maybe it’s related to how Cockpit is sending the values, or a lower level issue with how the MAVLink extension fields are parsed or something…

1 Like

The .BIN logs should help us tell what is going on. I’ll wait for those.

Apologies for my delay, and ignorance as I don’t know where the .BIN file is located.
Can I please get a few directions ?

Hi Ian -
.BIN files are autopilot log files, and are created when the vehicle is armed. Simply arm and disarm the vehicle a few times to get the behavior captured, and then download the latest log file from the Log Browser menu.

My Log Browser isn’t displaying any logs. Doesn’t matter whether I’m in Pirate mode or not. Log Browser shows nothing. I clicked the “fetch” button, nothing. What am I doing wrong here ? I did download the system and mavlink logs from the “cog” link; will those have the .BIN you need?

Hi @UnderseaROV -
Does your system use a Pixhawk or a Navigator? Did you leave the vehicle armed for at least 30 seconds?

_logs (1).zip (4.1 MB)
_logs.zip (1.7 MB)
Running the Navigator. But I saw the same symptoms on the Pixahawk.
I tried arming for 30sec, no change…noticed error message 401 for the file fetch. But saw the directory path, used the File Browser link to locate the attached .bin & .tlog files.
It was only for the last arming event/log that I let it run for 30 seconds. Prior to that I’d arm/disarm quickly to minimise spinning the props.

Hi @UnderseaROV

I can see part of the issue. The S axis, which gets mapped to pitch control, is slowly (negatively) increasing. I can’t tell from the logs why that is happening, as we don’t have MANUAL_CONTROL messages on these logs (but this not your fault).

It also seems the effect gets stronger every time you arm. each step of the red line is a new arming. and each brown spike is a thruster speeding up. if your S and T axis are un-mapped, Ardusub should receive zeros and just keep leveled. I guess I’m just re-phrasing what @EliotBR said. Another interesting thing to consider is that, as these axis are not being scaled, I have no idea of what is causing the input channel to change…

The lack of MANUAL_CONTROL messages on the logs makes it impossible to check if you were trying to adjust the trims for the thrusters to calm down, which could also be an option.

Since troubleshooting is proving to be hard, I’d recommend you to reset your firmware parameters to default, as well as Cockpit, then make sure R and S are unmapped in Cockpit.

Meanwhile I’ll see if we can get a blueos build with improved logging to get our hands on the MANUAL_CONTROL messages going to ArduSub

1 Like

Hi, we merged a patch today adding logging to mavlink-server.

Can you switch to BlueOS master, switch the router to MAvlink-server, and then replicate the issue? The resulting logs will then include the MANUAL_CONTROL messages.

1 Like

_ardupilot_logs.zip (3.6 MB)
I had a few delays getting BlueOS updated. The Log Browser is now populating and I grabbed the logs from today.

I armed for 30 sec. Disarmed. Armed and disarmed 4 times (5?) for shorter durations.

Are these the necessary logs ? @williamgalvani

Hi Ian!

I think you missed the step of switching to Mavlink-Server on the “MAVlink-endpoints” page. can you double check?

mavlink-server-2024-12-11-15-47-05.tlog (642.5 KB)

Got the same issues. Bluerov 2 heavy with navigator and cockpit. Stops if i load the Bluerov standard parameters.

thruster issue log.zip (129.3 KB)

Heres the .bin file :slight_smile:

@williamgalvani I definitely did make the setting change. It may have reverted or not applied. I will do it again in the next few hours and get the logs. Cheers.