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.
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.
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
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…
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?
_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.
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
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.
@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.