In recently doing some setup and pool testing of our custom ROV (made with 6 x T200 thrusters connected through a Navigator control board; operating BlueOS and Cockpit), we received an error message when trying to complete the “Detect Reversed Motors” function in the PWM Outputs page of Vehicle Setup in BlueOS: “MOTORDETECT failed. Need alt estimate”.
I’m hoping someone can direct me in the right direction for fixing this issue? Is there perhaps a setting that needs adjusting for this?
Hi @amurray -
Does your ROV use one of the ArduSub standard frame types?
Did you perform the motor direction setup with the vehicle floating in the pool?
Do you have a pressure sensor, like a Bar30, installed and reporting depth information to the vehicle?
You also need to calibrate your accelerometer and compass before you can perform the automatic direction setup.
Sometimes it can be faster to just manually check each thruster is spinning the expected direction when controlled via joystick in QGround Control or Cockpit!
It’s a custom built frame, but has the same motor configuration as the 6 motor vectored setup (as used in the BlueROV2).
Yes, vehicle was floating in the pool.
No pressure sensor on the ROV (as it’s only being used for pool based activities by students).
Accelerometer and compass were calibrated as well.
I have done a manual check now and adjusted for the reversed props where needed, thank you. I thought the automatic detection was a requirement, so I’m glad we could just get round this issue via a manual check!
The “Detect Reversed Motors” functionality is reliant on the vehicle being able to measure how it moves in response to directional control outputs. Presumably the vertical aspects of that make use of the vehicle’s depth sensing capabilities, which your vehicle doesn’t have.
Granted, it could be possible to detect vertical motion using the accelerometer, like is done with horizontal motion, but the automatic check is a convenience feature that was designed to cover the most common vehicles, so it’s not too surprising that it doesn’t handle all edge cases.
If it’s relevant, we’re in the process of enabling our Bar02 sensor for use with ArduSub, which is a little cheaper than the Bar30, and better suited to shallow depths like swimming pools.
I am curious where you got this impression - perhaps there is somewhere (in documentation and/or the interface) where we could specify that it’s optional, and that manual detection is a viable alternative? The automated checking is known to not be very robust to things like custom vehicle frames / mass distributions, so it’s a problem if we’re somehow giving the impression that it’s required!