After updating and setting the new parameters, ensuring you are running cube black firmware, (not FMUv3) and see what mission planner says. It will tell you if there is an issue.
If there is, simply contact your reseller
On 19/03/2019 We’ve ordered two Pixhawk Cubes, in a testflight undertaken on 07/01/2020 we could not get one of these modules to arm. One of our engineers pulled the following error messages:
“Gyro 0 fail”
“ACC 0 fail”
“magnetometer inconsistent”
Logfiles are not available since the system couldn’t be armed, we replaced the Cube in the system and everything worked as it should, indicating a problem with this specific unit.
You need to set logging while disarmed
Also check you have set up the board exactly as per the instructions.
You can also do a screenshot of the messages tab in mission planner
Our engineers stated to me that we are running a non-standard firmware and are therefore not able to follow the instructions as described.
They did their tests and concluded that the module had a hardware failure and that is how it landed on my desk.
I posted here since it was a requirement from our distributor in order to initiate an RMA procedure, we are beyond the troubleshooting stage for this module.
Please load the correct version of code and connect to mission planner with the correct parameters.
No need to fly it.
See if mission planner gives an error and get back to your distributor with the results
Hi, I have Quadcopter with Black Cube 2.1, AP 3.6.11 with the following prameters:
(INS_USE==1, INS_USE2==1 and INS_USE3==1, EK2_IMU_MASK==7)
I’m getting pre-arm errors of ‘Inconsistent Gyros’.
After many tests with my cube (Gyros / Accel Inconsistent) seems to me the only way I can avoid this without having to reboot is to disable IMU2 (i.e INS_USE2==0)
I know I’m loosing IMU redundancy, but I wanted to ask:
Will the IMU switching still work in case of an IMU failure with only 2 IMUs enabled (INS_USE==1, INS_USE2==0 and INS_USE3==1, EK2_IMU_MASK==5) ?
Is there a way to check this?
Thanks!
Yes, those settings are acceptable.
However, should not be necessary.
IMU 2 is noisiest, but unless it is stopping you arming, it’s actually useful to have around.
Have you tried a different cube? I’m happy to RMA it if it is but up to standard
Update to 3.6.12, if not jump straight up to AC 4.0.3
Not sure if that’ll fix your exact issues, but it’s highly recommended anyway.
Yep, time to move into the 4.x firmware
Yes, I’ve encountered this issue on a several different Cubes.
This is unrelated to the SB, please post in another topic or make your own topic
There are several topics related with this, the imu2 X gyro start to measure diffferent from the other IMUS
Update to 4.X doesnt fix if.
This hapen when tou turn on the drone and you dont move it or arm it. for me 15 minutes steady on the ground and I get that error…
After many tests without problems on the ground (I followed all the service bulletins) the first day in air I had an accident (June 2019) I took in the hand the copter in March 2020 for the reconstruction and after some tests on the ground without problems I have updated to fw 4.0.3 and the problems have started with orange led light and now a critical service bulletin pop-up.
If it’s crashed, it could have damaged the internal assembly.
This error checking will find it and flag it. It doesn’t discriminate as to how the damage happened.
So do you think that a crash that has not externally damaged the Cube protected inside the frame, frame that has not been damaged, except the landing gear, is the cause of a typical problem of that Cube series?
I’m happy to do a crash analysis for you. But there is no way I can possibly determine what may or may not have been damaged in a crash without a physical investigation.
Please start a new thread on this one, as it’s not a SB2 related issue other than symptoms
Hello @philip
I’ve faced the discussing issue after a first flight, and the recommendations provided above didn’t help.
The cube SN is CU11A9300680
Could you please suggest, should I contact the seller, or we may try to debug the issue remotely?
Thanks in advance!
There are no steps to “fix” this fault other than contacting your reseller
Understood, thanks!
I am getting the error: “Check BRD_TYPE: Failed to init CubeBlack - sensor”
I am running what I believe to be the latest version of Mission Planner: “1.3.72”
I have installed the latest ArduPlane firmware “4.0.5”.
I have confirmed that the Cube parameters match those as outlined in the bulletin.
The original error is persisting and I am unable to get the flight controller to fully boot. At this point in time am I correct in understanding that my only recourse is to request an RMA from Foxtech?
This is a little strange because I have flown 4 missions with this new UAV without issue, but in preparation for my 5th flight, this error presented itself.
Thanks