Philip can you please give some clearity. Irrelevant of the HW bug.
With respect of yesterdays update…
EK3_IMU_MASK == 7
INS_USE3 == 1
About Cubes from before 2019. Should we still do the following? I mean as defaults are 3 and 0 on those. What is best practice? Why was it zero previously, INS 3 I mean. Cube has 3 IMU right from the first day. So why was the 3rd not enabled be default?
Why this problem is arising in cube bought in 2019? Have you done any changes in hardware because all pixhawk boards runs on same software so why this problem is only arising in newer cubes.when I found the news of grounding pixhawk I immediately stopped flying. I want a total redundant and safe system. I do not want to harm anyone and after that checked the acclerometer parameters after your announcment and all of them are fully matching and then according to your instructions I updated the firmware and Mission Planner to the latest version and after that waited for atleast 1week.When i uploaded I do not got any warning)(After uploading firmware and updating mission planner to the latest version I newer tested it) but today when I connected to my mission planner thinking that may be the issue is resolved now but today I got the error that my cube is also sffected because of this message(Check BRD_Type:Failed to init CubeBlack). I want to tell you take your full time because it is the matter of extreme safety. Please provide an estimated time for this issue because on 25may I have to show my project to the government of India.
If you read above, we already said the issue is a failure in the PCB manufacturing process. We are evaluating how to determine exactly which boards are ok.
Please check everything I have asked you to check.
BRD_TYPE must be set to 3…
The code must be latest arducopter or arduplane loaded with the latest mission planner.
Your IMU’s must all be enabled
EK2_IMU_MASK == 7 (or EK3 if using EKF3)
INS_USE == 1
INS_USE2 == 1
INS_USE3 == 1
BRD_TYPE == 3
I do not have an estimate on time for this. It’s an ongoing investigation.
What you mean to say that the pcb board is itself is faulty?If it is the hardware problem then will you return the faulty cubes.If this is the hardware problem then it must be replaced? because only software problems can be resolved using firmware updates
There are possibly less than 1% of the boards are affected. This is within the acceptable scope of a $250 Autopilot.
The system is designed with this level of failure in mind, that’s why it is triple redundant!
However, the firmware that detects, and corrects such hardware issues, was broken in ardupilot.
So updating the software and setting the correct settings is your best protection from any possible cause of hardware issues.
If you have a board that the new software determines is faulty, log it with your email address through mission planner, and when we are able to, we will follow you up and sort it out.
We are not processing any exchanges at the moment, as we need to first guarantee that we get fresh new stock that is not affected.
Any exchanges will be done over time. We are not in a position to do this immediately.
This has all been discussed above.
Again, I do not apologise for grounding all of your aircraft.
What you want to say ?
If by any means you are not able to solve the hardware problem then also you will not provide costumer with the new board?
Please clarify that if we will be able to fly with the existing cubes or not
I appreciate your hardwork from last 15 days but I want to know how will you resolve the hardware issue with the software updates. I also not want to replace the cube because it is problamatic for you and me also. I just want to fly like before but any costumer who will come to know about the news that there was a hardware problem will get shocked. Because anyone will only buy your system because people think that this system has added security and nothing new from old pixhawk and paying a cost 3-4 times higher. I am not complaining about you but I am very disappointed because by collecting money from last 1 year I buyed this cube and not even a week passed and got the news of grounding. At last I only want to know that will I able to fly with my existing cube or not.?
Tbh you have to always understand that no hardware is with out the possibility of failure regardless of cost.
Philip has been extremely open and reacted very fast to this, in around a week of a few reports they released the bulletin grounded potentially affected models and very quickly after that was able to give a clear explanation of the cause and why it’s happened. He quickly helped get mitigation into Ardupilot improving the redundancy behaviour for everyone using it and got a notification system into Mission Planner to identify affected units quickly too.
This all in its self should be enough in virtually all but very few cases prevent a loss in flight as long as people are using latest Ardupilot firmware, it should also be noted that the actual causes of the crashes was as much to do with the Ardupilot behaviour with multiple sensor redundancy failure as it was the actually loss of the IMUs, the whole reason for having triple IMU is to allow the software to recover if something failed and it was not in this case.
Now Profi are in the sorting out affected cubes stage and they just need a little time to get this all worked out but people do need to be patent, no one has said people won’t get their cubes sorted but a rushed response is worse than no response at all when it’s not able to actually help users.
They have been extremely fast to react to this and actually should be given a LOT of credit for their transparency and quick reaction on this overall.
No one wants or likes failure but it does happen regardless, what’s important is it’s identified and delt with properly and if that takes some time then so be it.
Have you updated to the latest 3.6.8? Have you connected to your cube with mission planner or qgc after updating? Did you get a warning about this SB? Check your BRD_TYPE param for “3” (cube black)?
As of 8 days ago, Philip reported only 9 affected cubes…
You’re right - a software bug fix does not address the root cause hardware fault. But the latest SOFTWARE update was required to DETECT the HARDWARE fault. Without the software fix first, we would have had 0% chance to detect the fault before a crash.
I am just as frustrated by this as anyone cause I just want to fly with this super dope top of the line flight controller I just got, but keep in mind that defects like this do occur in manufacturing all the time. As consumers, we rarely if ever hear anything about them let alone overnight explanations from the people who designed and manufacture it. This is unprecedented to see this much transparency about a manufacturing defect.
I am not affiliated with CubePilot so I can’t speak to how they will address the affected cubes, but I personally believe that they will make the end users whole in time.
Before getting news of grounding I am flying very well but as soon as I updated mission planner and firmware Till then I was not able to fly. What immediately caused cube to be grounded? Can’t we at our own risk fly like before without redundancy on sensor