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

But what happens if i buy one off joe blow that has old stock but there new and is a lazy ass to send them back ?

Always purchase from an official reseller

what the problem is ?

please contact your reseller for the replacement. Thank you

OK, I have this bulletin and setting up as the build proceeds. The airframe is an octocopter to run on S6 LiPo batteries and SimonK ESCs, though I’m not there yet.

In configuring compasses in the flight controller module, QGround Control tells me sensors are upside down and back to front, as follows:

upright <-> upside down
front <-> left side
rear <-> right side

I downloaded the CUBE_BLACK.param file indicated above, and tried to load file but can’t see any result.

I am using RadioLink SE100 GPS/Compass units and have checked the wiring harnesses to make sure I have the pins correct, with the same results.

Is there something I am doing wrong, or more I need to do?

Any help, thanks in advance.

Gil

First, setup without the GPS, to eliminate that.

Second, use mission planner.

Please ensure you have fresh default parameters, then load the special parameters.

If it is all good, then you have a different issue.

I had purchased new 4 cube. Out of one cube had issue of above and got pop up window after connecting Mission planner. The other 3 cube are working on ground. The issue with other 3 cube is , not able to do firmware upgrade from QGCS and able to do from Mission Planner. Please let me know why it is not able to upgrade firmware from QGCS, as older cube is able to do…

Your question is not related to this service bulletin, please ask elsewhere.

Update QGC

When I try to load your special parameters, Philip, Mission Planner tells me there are 6 missing parameters, listing those in your .param file.

Are you running the correct firmware?

Hi @philip,

I have read all post, but I don´t know if my cube is affected. It was boughT (not marked with “Pixhawk 2”) on January 2019 but i don´t understand your post which you said:

Which screws holding the lid down? In the cube itself or the lower lid of the pixhawk.
Could you tell me if this cube is affected with this pictures?

Regards.

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