Motor's PWM failed after armed (Navigator board)

Hi guys,

After successfully installed our own custom 4.1 Ardusub firmware, we have tested it but as soon as we armed the vehicle, all PWM signals from the motors dropped to 0 and restarted as soon as we disarm the vehicle. Below are some figures of PWM signals dropped out.

However, this only happens when we armed the vehicle. When each motor is tested separately, they are working fine with Qgroundcontrol 4.23.

We then went back to install stable firmware on BlueOS but this issue still persists (PWM not working when armed). I have also attached some log files as well.

log_4_2022-6-8-09-53-56.bin (823.6 KB)
log_5_2022-6-8-10-02-14.bin (418.9 KB)
log_6_2022-6-8-10-19-02.bin (1.9 MB)
log_7_2022-6-8-10-22-47.bin (1018.3 KB)
log_8_2022-6-8-10-30-55.bin (219.2 KB)

Update: We also tested with another Navigator board but same issue still happened (BlueOS can detect the board). The 2 boards are also tested in MAVproxy as well.

I then replaced the Navigator board with Pixhawk (with Ardusub 4.1 custom firmware installed) and they are functioning normally.

Hi @qnguyen,

I’m not sure what’s going on here, but I don’t think it’s something we’ve seen - I’ve brought it up internally with the software team in case they have some ideas.

The ArduSub-stable tag is pointing to 4.1.0 now - could you try flashing that to see if it works, and if it does then potentially rebase your modifications over that? :slight_smile:

Hi @EliotBR , I have tried flashing 4.10 stable on BlueOS but that issue is still ongoing, I am not quite sure what is happening as well. I am just being curious if the parameters have anything to do with the motors.

There are several parameters related to the motor outputs, and how ArduSub treats the inputs from the operator. I haven’t looked into that in depth though, so I’m not sure what the most likely causes would be of a problem like the one you’re experiencing (which is why I’ve brought it up internally).

Out of interest, have you changed anything in your custom firmware other than the frame configuration?

Outside of that my main ideas would be to double check the failsafes on the Safety page, and making sure the sensors are calibrated.

It’s also possible the “lost manual control” on both your screenshots is related to the issue (perhaps there’s a communication problem or something?)

Please try resetting the parameters to firmware defaults in QGroundcontrol.
You can do it in the parameters page:

I manually changed some parameters in AP_Motor6DOF.cpp for the custom frame built for 8 motors ROV
and then compile it. But then, we used a parameter that we set up for an ROV so it may conflict with 4.10 firmware !!
We will try to attempt another try with it. Thank you

@EliotBR @williangalvani It is actually conflicts between parameters from 4.03 and 4.10. We imported same parameters to a new Pixhawk and it behaves the same way. Fresh restart on parameters fixed the problem !!! Thank you so much for your assistance.

1 Like