As you had the wrong firmware and parameters, it may not have been looking for it.
If 3.6.10 works, you are all good
Philip, I would just like a clarification regarding this statement:
â8. Further flight is only to be conducted where you have carried out a full risk assessment on the implications of a failure occurring, the new code is good⌠but it should not be relied upon as your only means of protection. You must not fly over people, you must not fly over critical infrastructure, you must also take responsibility for your payload and vehicle.â
Are these limitations only meant to apply if Mission Planner has flagged the unit, OR should they apply regardless as long as the cube is purchased within the affected period?
I have one of these units but nothing has been flagged yet and everything seems fine (and yes, I am running latest firmware with advised param settings). I just canât convince myself if it is as safe to fly compared to running a device without this PCB flaw⌠I tried to contact my dealer (FoxtechFpv) as I would feel better with a âknown goodâ cube, but the offer I got was a bit involved, and would ground me for many weeks probably⌠(as disassembling the entire kit, shipping it to China, eventually get a refund and then order a new kit somewhere elseâŚ) Just wonder if you could share your opinion on this. Thanks.
Iâm not sure what else to add, the code is great, but risks exist with everything.
1 Like
Is this error âCheck BRD_TYPE: Failed to init CubeBlack - sensorâ related to the error in this topic? Are there any fix or do i have to change the cube with a new one?
Yes, that is the first indication.
Make sure you have the parameters all set
And contact your reseller for an RMA
Hi philip,
I have a Pixhawk Cube 2 and after some issues I found this topic.
I checked if the IMUs was working and I found:
INS_ACC_ID 1442826
INS_ACC2_ID 0
INS_ACC3_ID 0
I use the MissionPlanner 1.3.68 ad is installed on the sd the ArduCopter V3.6.11 (f0d59294).
I have to contact the reseller?
Thanks for the help
Riccardo
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.