SB_0000002 Critical service bulletin for Cubes Purchased between January 2019 to July 2019. DO NOT FLY

You purchased in January, please follow the instructions

Is exist some page for verification of version Cube (if it is from new series or not). Because I have ordered 1pcs from Robotshop and I don’t know if it is old or new series.

All users should be running the latest firmware regardless of when they purchased their cube.
This new firmware and latest mission planner will look for any issues, and attempt to protect you from faults.

1 Like

I RMA’d my cube through robotshop a few weeks ago. If your order shipped after 6/18, then it is a ‘new’ cube. I’m pretty sure I got one of the first of a new shipment from them.

Beyond that, the rate of occurance is very low. You have good chances of having a healthy cube. Mission Planner and QGC will both detect failures.

You need to look at the bottom.

Early Cubes labelled both Cube and Pixhawk has the clear base plate held on with 4 screws around the side, later cubes have 4 plastic clips with no screws around the side.

Technically Philip said only the later ones with the base held on with clips are affected however regardless the simplest answer and the safest thing to do is to make sure you are using the latest mission planner for it to detect yours and fly latest ardupilot.

Most importantly regardless of affected model or not is it’s highly advised to run latest Ardupilot and set the specific cube black settings enabling the 3 EKF’s to ensure you have proper IMU redundancy. This can only be done with Chibios on the later Ardupilot.

I have seen PX4 have put some code in around this too in V1.9 however this is not supported officially.

Thanks for your explanation. You have resolve my doubt about the base with clips or screws.

Regards

Help Please…
I am getting the error when i try to connect my pixhawk to MP.
Check BRD_TYPE Failed to init CubeBlack-sensor
i have tried everything mentioned above but still getting the error…
Any Solution.?

There is no “resolution” if you get that error other than doing an RMA

Hello Philip,

Our company uses Pixhawk 2.1’s in our UAVs, the vast majority of which were purchased after January of 2019. We fly hundreds of flights per day and for the majority of our fleet, our Pixhawks function perfectly well and reliably. However, in the past few weeks, we have had frequent problems with 2 specific drones in our fleet. They both have Pixhawks that were purchased after January 2019. We have successfully diagnosed many issues throughout our years of operating, but it seems we are at a loss regarding what’s plagueing these drones in particular, and we can’t help but think it is related to this bulletin, and may be indicative of a larger, looming problem that may be affecting other members of the Pixhawk community. These 2 drones have gone down repeatedly in the line of duty in the past month, seemingly for no reason. We have tried to set the INS parameters as per the instructions in the original code, however, our Pixhawks output the following error: “NavEKF2: allocation failed”; we had to revert the parameters in order to get these drones to fly. We have logs of their crashes, would you be able to review them? I know you’re extremely busy; but I believe that given our extensive flight heritage, you might find these logs to be particularly interesting and I’d hope that analyzing them could give your team and the community at large some additional insight. Like I stated, we have flown thousands of Pixhawk 2.1 flights and out of all of those, these specific drone crashes remain a mystery to us. If you can, let me know where I can send the logs to you for analyis.

Thank you

If the recommendations from us cause the vehicle to refuse to fly…

DO NOT FLY IT!

I’m sorry to use caps, but this sort of post really really irritates me. We are in the aviation industry people! If a manufacturer issues a service bulletin… FOLLOW IT EXACTLY!

Even thought the errors you have would indicate a different issue, the code is protecting you from whatever is going wrong!

Post logs to a new issue, and please, please NEVER TAKEOFF with any safeguards bypassed.

Please start a new topic, and post the logs to that topic.

BTW… I love your stuff! Keep up the good work!

1 Like

I appreciate it. As you said, I posted the logs in a separate topic, you can find it here: Mysterious Crashes with Post Jan 2019 Pixhawk 2.1's - Log Analysis

Thank you for the help!

1 Like

I got my repaired cube today and as soon as I connected it to my laptop the gps module shows a beautiful blue led which I never saw before. I want to know that is this phenomenon normal. Does I need to check the INS parameter also, I got my cube repaired and also do I need to upload cube black_Param now after getting repaired cube

Yes, you need to load these parameters.

in case nobody saw it, arducopter 3.6.10-rc2 is out please use 3.6.10 on your vehicles now thank you

I got my repaired cube back and today I plugged it into the board and when I clicked on upload firmware I saw a popup menu screen. Photo is attached below

I just wanted to know that what to fill in this
In type I selected copter
Version Type-official
Platform- cube black
Version-3.6.10
Format apj
USB Id-???
Board ID-9
Boot loader id-???
Firmware-???

What to fill in the three blank fields
And one thing more do I need to check the parameters listed above after getting it repaired and do I need to upload cube_black firmware also


One last thing that after getting my repaired cube always when i power it up the here2 gps shows blinking blue light which I never saw before, is this normal

Please ask this in the cube section, yes, all users must use the parameters specified

We’ve switch over a large amount of drones from 3.6.5. To 3.6.8… Now we have to switch them all 3.6.10? Is this really neccesary? The issue is that we have drones in many different locations and now we have to have everyone of those drones updated once again??:expressionless:

Yes it’s absolutely necessary, you need to work out how to keep your code up to date regardless of if it’s due to a service bulletin from us, or if Ardupilot just put out an update.

Software updates come out all the time, to fix a massive array of issues.

Keep up to date, or risk unnecessary injury, death, crashes. That may appear a little harsh, but if you are releasing “professional” systems based on the FREE ardupilot firmware, the least you can do is stay updated