I was using full vectored6dof t200 configuration in my past robot but the 1,2,3,4 motors are doubled (1 signal to 2 esc and 2 motors)(in total of 12 motors). And this configuration worked very well.
Now, I built a full vectored6dof t500 configuration, and again 1,2,3,4 motors are doubled(1 signal to 2 esc and 2 motors)(in total of 12 motors), and now one of the motors keeps turning. Here is the video of problem:
Let me explain the chronology of problem:
at startup of the robot, when there is no arm or disarm command, the motors are standing still.
when I arm the motors the rear,right,upper motor keeps turning(in the video).
when I disarm the motors the rear, right, upper motor keeps turning but this time slowly.
when I send some joystick commands(for example forward, backward or smth else), this time some motors in the front side keeps turning, but when I disarm it stops.
At a guess there may be some clock speed misalignment between the ESCs and the control hardware’s servo outputs, either due to actual misalignment of the clocks, or some kind of parasitic electrical effects.
That might be fixable by adjusting the trim of each output to better match its ESC (although that’s not currently supported by ArduSub), but given you have multiple ESCs connected to the same output you would need to also make sure that paired up ESCs have similar electrical effects on their signal wires, and that they have closely aligned clock speeds.
There’s also some possibility that the autopilot is outputting incorrect or unintended values, which you should be able to check by monitoring the SERVO_OUTPUT_RAW MAVLink messages and seeing whether the output pulse-durations are set to 1500µs when you expect the motors to be stopped, and seeing whether any motors are moving while the pulse-duration is set to 1500µs. In either of those cases there may be some unknown autopilot bug, but the case may be resolved by re-calibrating your joystick (or trying a different one).
There may be some issue with the accuracy of the clock chip on it. Diagnosing that is best done by checking the pulse-durations of the input signal with an oscilloscope, and seeing whether it is moving the motor when it shouldn’t be. If that is the case it’s likely still usable by adjusting the trim of the output that’s controlling it, but as mentioned that’s not currently possible with ArduSub.
If it’s not working as expected then I’d recommend contacting email@example.com, and linking them to this thread for some context, as well as providing your order number (or at least rough order date), so we can track the issue internally (to try to check for or prevent it in future), and provide you with a replacement or refund if it’s relevant to do so