Failed to Init Cube Black - sensor after upgrading older cube

Cube Autopilot
1

I’m new on here but have been flying a cube black for many years now.

I’ve come to upgrade recently, and after upgarding to 4.07, am now getting the error “Failed to init Cube Black - sensor”

My parameters are all set as per the SB at the top of the page, and I’m still getting this error.

I’ve been running 3.6.7 for the last while with zero issues, and as my cube is 4 years old, I don’t see it being affected by the sensor issues in the 2019 cubes?

Can anyone shed some light on what the issue may be? I want to make use of the lua functionality in newer versions, but it’s extremely frustrating when I have what to all intents and purposes is a working cube but I’m not able to upgrade.

Any pointers greatly appreciated

2

Check the BRD_Type pram is correct.

Otherwise follow the process in the bulletin to see if al the sensors are showing correctly.

It’s possible you have had an issue that’s been masked but dig a little deeper and look at the specifics for each sensor.

What’s showing in the HWId Screen

3

BRD_TYPE was set to 3. I’d made sure all the params were set as per the bulletin.
Below is my hardware ID page from while running 3.6.7

Capture
Capture704×266 37.7 KB

And here is the same from 4.07

4.07
4.07746×398 57.4 KB

I see the issue now! Is that saying that my hardware is too old to be running the latest versions? (My cube is one fo the ones marked “cube” below the pixhawk2, and I’m using a Here 1 for GPS

As far as I can tell my sensor are all working correctly, but I’d be the first to admit that once it gets into the nitty gritty of the underlying code I’m not too clued up as up until now everything has been working and haven’t neede to look at it too much

4

No it should work fine with latest release too.

Sensors appear to be fine looking At the page.

Make sure you are flashing it as a Cube Black and not Pixhawk, even though it’s label is Pixhawk 2 it’s a Cube Black.

Also are you restoring prams ?

I would try as follows.

Flash latest Ardurover selecting cube black then back to copter again selecting cube black but don’t restore the prams. You will need to manually reconfigure.

5

I upgraded first using the firmware button in QGC, which also restored all my params. All using cube black from the drop down

Since then I also tried flashing rover, and back to copter to get a clean install, but immediately after the reboot I start getting the same error, before I’ve even started to manually re-configure. Even after making the service bulletin changes I still have the same message.

I did try also setting the service bulletin parameters in 3.6.7 before upgarding in the hope that this would behave differently, but I still get the same result.

6

Can you try to flash the firmware in Mission Planner?
Connect the Cube -> reset all parameters to default -> flash rover/plane -> flash copter -> connect and see if the error still pop out.
Don’t change any parameters during the process.

7

I had tried the flashing rover using QGC, and have tried using mission planner to update to the latest version, but I hadn’t done all of it in mission planner before. I’ll give that a go tonight.

When you say reset all parameters, I assumed flashing rover would do that, or is there another method too that I should be resetting copter before flashing rover?

8

Use the Reset to default button in Mission Planner parameter list page.

Yes flashing rover will reset copter. Resetting parameters before that is just to make sure everything is cleaned

9

So I’ve just followed that procedure
Reset all Params, then flashed rover, I get a slightly different message - Failed to init CubeBlack - sensor mi (I presume because of differences between rover and copter)
I then reloaded copter and get the same message again. I did notice that EK2_IMU_MASK was set to 3 rather than 7 and loggging before arming was disabled. All the rest were the same, so I changed the two as required, and rebooted, but still get the same issue.

I’m not sure it will be much use, but here are the messages after rebooting, and re-connecting.
image

My log from after rebooting is below too, along with my parameters after a clean loading of copter and having only updated the 2 parameters to match the bulletinData.zip (174.5 KB)

I’ve just had a look back through my emails, and I bought the cube back in July 2017, which is why I’m a bit confused why I’m getting the warning about my cube being affected by an issue from 2019

10

Cubes from 2017 shouldn’t have SB02 issue.
Can you make a disarm log with the 4.0.7 firmware?
Also, may I know if the housing of your Cube is the one which secure the bottom lid with screws?

11

I’ll grab some logs tonight when I get home from work and post those, as with the housing, I’ll need to take it off the frame and check, so will get that tonight. I do know it is still labeled Pixhawk2 on the housing, and has cube printed in smaller text below that

12

Ive just taken the cube off the carrier and double checked, and it has 4 screws around the side holding the cover on.

image
image1179×855 114 KB

image
image1041×850 172 KB

I’ve also followed the previous proceedure again to put 4.07 on Reset Params > Load Rover > Load Copter and updated the parameters to match the SB, then rebooted, and the log is attached below. I had to download it as a BIN file via mavftp in mission planner, then converted it to a log file in mission planner
00000227.zip (1.3 MB)

13

From your log, the IMUs are still sending out data.
Can you check the HWID page whether the device ID are showing correctly?

14

As far as I can see they are all there correctly

image

15

All sensors are correctly detected yet the SB02 warning still pop out? Interesting.

Can you send it back for inspection?

16

Yeah, I can send it back to be checked over. Should I send it directly to you, or should I go via the original supplier.

As we’re finally getting into better weather here in the UK, how long do you think I would likely be without it, or would it be as an exchange?

17

Please go through the original supplier.
I am not sure how long would it take. Normally you’ll get an exchange if we are sure it is a hardware failure, but for your Cube we need to investigate what happened inside.

18

No problem, I’ll make contact with my original supplier (UnManned Tech Shop in the uk) and get it sent back for investigation.

Do I need to give them any info regarding the return info, eg link them to this discussion, or will you contact them.

19

I have shipped the cube back to my original reseller yesterday, so that should be with them in the next day or too.

20

Stefan,

Did you ever find out what this issue was or did they just swap the cube out? I started having the same issue. I was on 4.0.7 and all was well until I started some upgrades on an RFD900X telemetry modem (TXMOD) and also I upgraded to 4.4.1 I tried going back to 4.0.7 and now get the exact message you had above.
On 4.0.7 I get " Check BRD_TYPE: Failed to init CubeBlack - sensor "
On 4.4.1 I get “Config Error: fix problem then reboot”

I have checked the parameter values in the SB.

Thanks.