The last state of affairs as per manufacture (who is the only authority on the subject) is that the investigation is not concluded yet. Flight ban has been lifted to “fly at your own risk, with precautions”.
If you read the first post and that last few ones by Philip. You will see that he promised to. Let us all know when we get an “all clear” on a Cube purchase.
Manufacturer:
“We are working hard with our full supply chain to get proven product out the door ASAP”.
I am sure you will get an update here as soon as there is any development. They have been very good with updates.
There are an incredible number of Cube (2019) out there flying every day. Less than 1% was affected even before the software was fixed since, to notify you about such failure. So the risk is really really minimal. However it is aviation…
If a cube had been flying fine with no symptoms, but actually started to fail without showing symptoms - would we expect the service bulletin warning to show up at the next mission planner connect?
…or would it require a ‘factory reset’ of sorts by reinstalling any version of ardupilot before the service bulletin warning showed up?
I assume mission planner identifies affected boards via scanning the parameters (the little window says ‘via param scan’). Does it look at things like INS_ACC_ID and INS_GYR_ID? The problem is that those parameters are marked as ‘read only’. So if a board actually does start to fail and MP is checking those params, they wouldnt have changed due to their read only state and MP would have no chance of identifying failure until the user does a clean install or next release install.
I have a pixhawk cube, purchased 2017 using ardurover has been working fine until Sunday when I upgraded to latest mission planner upgraded firmware to 3.5.1. Now mission planner won’t recognise board.
@philip - are replacements through resellers after getting service bulletin warnings known to be be safe at this point? Or are we still crossing our fingers on low probability of failure with replacement units, too?
Is the latest instruction for service bulletin warning in mission planner to get it replaced through reseller?
Hello there,
thanks for the great support on this topic!
I have done all the steps that @philip suggested and my pixhawk seems to work fine. No error messages and MP doesn’t flag the code.
Now I am wondering:
If I want to use it for arduplane do I as well need to change the recommended parameters to: #NOTE: CUBE_BLACK
BRD_TYPE,3
EK2_IMU_MASK,7
INS_USE,1
INS_USE2,1
INS_USE3,1
LOG_DISARMED,1
??
thanks for your help. I hope this is the right thread to post this question.
Plan on getting the Pixhawk 2.1 Cube in a few weeks for a fixed wing build.
Has this issue been resolved? If I buy a new Pixhawk 2.1 cube in a few weeks and being new to all this, I’d rather not have do any work arounds to ensure I have a safe FC.
Less than 0.5% of 2019 cubes were affected by the issue, the new code identifies these quite effectively, catching most on the ground, and effectively switching IMU’s in flight if the multiple preflight checks do fail to find the issue.
A faulty cube will report as such, and you can send a report via mission planner.
Anyone that had one of the faulty cubes can contact their distributor.
All other cubes are good for flight.
HOWEVER!!!
we do not guarantee any cube is perfect, nor do we guarantee that ardupilot or PX4 is bug free. (For the record, both ardupilot and PX4 are much more reliable in my opinion than any other offerings, commercial, military, or open source). As anyone that watches air crash investigations will understand, things go wrong… we cannot and will not guarantee anything other than the hardware, and we only offer replacement of the broken hardware if a hardware fault occurs.
We have on many many occasions asked people to contact their resellers. Your reseller is the official channel, and this discussion is the official discussion on the matter
Hi, I have a 2018 Cube. Last Mission Planner and last firmware.
The INS_ACC_ID (1, 2, 3) and the INS_GYR_ID(1, 2, 3) values were the indicated as OK: 1442082, 1114914, 1442826, etc.
Then I loaded a param file I have from a previous Pixhawk 1 Plane I wanted to replicate, and saved. After that, I checked that some of the INS_ACC_ID and INS_GYR_ID were 0.
So I reloaded the original Cube param file and the values were again 1442082, 1114914, 1442826, etc. Then instead of loading the full Pixhawk 1 parameters I used “Compare Params” to load only the ones I needed to not modify the INS_ACC_ID and INS_GYR_ID.
