Hi, i need help. Recently adquire a br2 with the heavy config. The first thing i did was un update to the rpi and pixhawk and download the ultimate qgc then in the pool i perform the motor configuration test with the result “Failed! Please check Thruster 5 and frame setup!” so i did, i check the thruster (it´s ok) and the frame setup is correct (6dof) i also change the Esc and motor after trying many time with the same results. After all no changes, same error “Failed! Please check Thruster 5 and frame setup!” after that I test how its move in the water and surprise… backward is forward and viceversa. please help…
Hi @Mauro,
Can you confirm that when you manually do the motor tests, the correct motors (for your frame) are spinning at the correct time?
The automatic direction detection test tries to determine whether a thruster should spin one way or the other, but it assumes all the thrusters are plugged into the correct numbered positions in the Pixhawk, so if it’s expecting roll, pitch, and vertical motion from thruster 5, but is actually getting forwards or yaw motion when it tries to run thruster 5 then it will fail the test and give you an error.
@EliotBR Eliot thanks for your attention, in response to your observations:
the motors (all) are spinning at the correct time and plugged into the correct numbered postitions in the pixhawk. the rove moves very well in all directions except for the issue with forward and backward (are changed) when you want to go forward it goes backwards and viceversa. as i mentioned before the qgc are the las stable version and also the rpi and pix firmwares. Please help…
I’m a bit confused by this. If moving sideways and turning works as expected, but forward and backward are switched, my main thoughts are either
- some thrusters are getting input from the wrong Pixhawk outputs
- either the thrusters are connected to the wrong ESCs, or the ESCs are connected to the wrong ports, or
- in the joystick calibration you’ve done the forwards/backwards part of the calibration backwards
- but in that case I don’t see why it would affect the automatic motor direction detection
hi eliot,
I made my own configuration, compiled and uploaded. Vehicle directions are correct and move as desired. When I put it in the engine test, it also says 5th engine configuration error.
my config work here can you help me ?
Hi @ramazan, welcome to the forum 
In your diagram motors 5 and 6 should both have contributions to the vehicle pitch, but you have put 0 as their pitch thrust factors. The automatic motor direction detection is a convenience tool that tries to detect whether the motors are reversed to their thrust factors. If the factors do not accurately describe the motion contributions it’s very possible for the direction detection to fail.
I would recommend including the pitch factors, but the most important thing is for the vehicle to operate the way you expect it to. If it’s moving as expected then you don’t need to run the automatic direction detection test, because the directions are already correct.
I solved the configuration problem. Thank you.
I can’t see the pressure sensor and camera settings on the “vehicle setup” screen. But I installed the standard version instead of “Custome firmware” and there seems to be no problem. Why can’t I detect the camera and pressure sensors? Also, when I do not calibrate the compass, the red warning light does not appear on the screen. I think it’s a general problem with “Custome firmware”.
https://firmware.us.ardupilot.org/Sub/stable-4.1.0/Pixhawk1/ I installed the adj file I downloaded from here and there is no problem. I think I had problems with compiling. I’ll have to look into these issues in detail.
This(4.2.2) version has problems. Problems were fixed in version 4.1.0.
There is no 4.2.2 version of ArduSub available, so I’m not sure what you mean by this. The latest releases are 4.1.0 (stable) and 4.1.1 (beta), and development builds should currently show up as 4.2.0-dev.
EDIT: I had some vague recollection of a similar problem, so searched the forum a bit. In case it’s relevant, I managed to find that there has been a previous report of reversed controls, but that was seemingly an issue with a developmental version of QGroundControl, and we were unable to confirm/replicate it at the time.
I wrote it wrong, I meant 4.2.0. If we compile 4.2.0, there are problems that I mentioned. If I run with 4.1.0 from githup it’s fine.