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

[ekliptiko (Ted Weerts)]

I was holding on to hopes and prayers that my distributor had old stock that is not of concern here.

@philip

At this point, we are just looking at the software methodology.

The cubes marked “Pixhawk 2” are not in the suspect range.

The cubes marked “cube” with screws holding the lid down, are also not in the suspect range.

Once we have narrowed down the date range, we will add all potentially affected cubes to the auto detect list on mission planner

…but i think i am out of luck. looks like my cube sourced from a distributor is post-Jan19. Due to “CUBE” marking on top and clips instead of screws holding the lid down.

My cube setup has not shown the SB warning in MP, HW IDs match, BRD_TYPE is correct, no “init Cube Black” errors and no INS errors. Which is awesome! But that is all on the bench. Knowing what we know about this fault, is it possible the symptoms will show after some time? maybe simply powered on time with current flowing? or after a few flights?

[philip]

Letting it cycle hot and cold over a few days, 30 minutes at a time is the best way.

It’s less than 1% of cubes that are affected out of just two batches.

With latest code, if it occurs inflight, it should fail over correctly.

It’s up to you to determine if it is safe to fly

[ekliptiko (Ted Weerts)]

He is refering to Mission Planner providing a warning about this service bulletin. the popup looks like this in mission planner:

@Wolfgang-BN

…and this in QGroundControl:

@DonLakeFlyer

Screen Shot 2019-05-01 at 8.50.41 AM.png1140×430 764 KB

@philip

If Mission planner flags your code, contact your local re-seller, and log the issue. DO NOT FLY TILL I HAVE PERSONALLY CHECKED YOUR LOGS, and either given the go ahead, or, organised what we will do next in your case.
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.

[ekliptiko (Ted Weerts)]

Roger that. Flight risk is all mine. Im still bench testing cause im anxious about this fault.

Ill power cycle it several times on the bench and see how it goes. Hopefully this will be a no news is good news kind of situation.

[Norimbo]

Hi I have 2018 version of cube. I just updated to 3.6.8 firmware and chibiOS. By default I had:

EK2_IMU_MASK == 2
INS_USE == 1
INS_USE2 == 1
INS_USE3 == 0    

as I understand It will be safer and better to fly with option:

EK2_IMU_MASK == 7
INS_USE == 1
INS_USE2 == 1
INS_USE3 == 1  

??? So I should change this in my 2018 cube ?

[philip]

Correct

[sumit2002 (Sumit Singh)]

What do you mean by flags the code

[sumit2002 (Sumit Singh)]

Why you are not releasing the firmare which you tested with multiple imu failure

[philip]

Your question is confusing…

The firmware that is released now, as mentioned in the primary post, can handle multiple failures.

What firmware are you talking about?

[ekliptiko (Ted Weerts)]

Dude.

It has been released:

https://discuss.ardupilot.org/t/copter-3-6-8-released/41569

[Giovane_Munhoz]

Hello guys, I’m a new cube user and I may be affected on this bulletin. (bouth on 02/13/19 from ir-lock)

I’ve followed every instruction that was told to follow and read all comments in this page, i’m using newest beta version mission planner, arducopter 3.6.8 hexa, changed the board parameters and MP didnt warn about the service bulletin until now.

I know that is massive, but I can fly safely ?

FYI I’ve never flew with this board I just turned it on a few times, its a brand new board and i’m still running heating and cooling cicles, as philip said, and until know, MP dont warned about the service bulletin.

Thanks all.

[philip]

@Giovane_Munhoz

I know that is massive, but I can fly safely ?

Please read the last step… before flight, do a risk assessment, and you decide

[sumit2002 (Sumit Singh)]

But in this firmware we have to upload the cube black code by our own which I tried as stated above and after rebooting only once I was able to arm the copter and then after same error is shown in mission planner. I am asking you to give us a fresh firmware in which all parameter are set by default by computer itself. Because uploading the code manually is so confusing. Despite following instructions listed above I was only once able to arm the copter. If you will release the parameter in a firmware form we have to not do it manually. I uploaded the previous firmware and able to fly but I will not fly in future with previous firmware I was jus testing it. Many users above also listed the same issue that despite uploading cube black code they are getting error

[philip]

Regardless of parameters in the code, these need to be manually checked.

[sumit2002 (Sumit Singh)]

But why after checking these codes also we are not able to make it run

[philip]

If you get the error on mission planner that the cube black sensors are not working, then you have a bad board.

If you don’t get this error, but you are having issues, please start a thread, and post logs… because you have a different problem.

[hdtechk (L Kurt Shaw)]

Are you still using nuttx instead of chibios? The check is only in Chibios

[sumit2002 (Sumit Singh)]

. ChibiOs. I mentioned that I was using all the latest softwares possible

[sumit2002 (Sumit Singh)]

Despite of using latest mission planner and uploading latest firmware on the board and after uploading cube black code I am receiving the same error Check_BRD_TYPE FAILED TO INIT CUBE BLACK SENSOR.I think my hardware is faulty,so what to do now or what are you doing to solve this.

[philip]

Please read the notice again…

In the case of your board… you need to contact your reseller, and have them contact me.

Any further questions, please ask your reseller