I plugged my cubeBlack into my laptop via USB, but got no bootup beeps. I gave the pixhawk external power and then it initialized, but got these messages:
I am having the same issues on a Cube Orange. I have done what was recommended but I still have the error. @bugobliterator I have discord if you would like to have a chat.
I am back at it, trying to figure out what is happening. I have actually found out that the barometer is probably the first that is being check, but in reality, something is wrong with the sensor drivers. No sensor appears to be read. PX4 works on this board. I have opened a issue here.
Thanks for the report. Do you have any other Cubes around to test? I suspect that the board’s barometer is malfunctioning (which is quite rare) and this is how 4.1 is handling it.
PX4 not discovering a broken sensor, unfortunatly doesn’t surprise me at all, we strongly reccomend against PX4 for this reason.
ignoring broken sensors on takeoff is a very bad thing to do.
I suggest getting an RMA, I have tested that virsion of firmware here and have had no issues, however, once I can load your parameters into the cube, I will try again, just in case.
Sorry about the log access. I updated it now. We have other boards already installed with 4.1.3 and all is fine. This board was functioning just fine with 4.0.5 before. I checked the flight log out of curiosity and I do not think there is a way to distinguish between the barometers but at least the pressure seemed to be read correctly.
I installed PX4 and tried to see if there was a second baro that I could somehow verify it’s conditions but I was not able. I will get to the workshop in a few h and check with a board that is fine to see if that one sees 2 barometers or PX4 just uses one baro with the CubeOrange. I got lost in their code trying to figure out if for this board both barometers are used.
A snippet of what I tried
nsh> ms5611 status
INFO [SPI_I2C] Running on SPI Bus 1
ms5611: read: 18231 events, 229629us elapsed, 12.60us avg, min 9us max 59us 1.462us rms
ms5611: com_err: 0 events
device: ms5611
nsh> ms5611 stop
nsh> ms5611 start -I
WARN [SPI_I2C] ms5611: no instance started (no device on bus?)
nsh> ms5611 start -X
WARN [SPI_I2C] ms5611: no instance started (no device on bus?)
nsh> ms5611 start -s
ms5611 #0 on SPI bus 1
nsh> ms5611 start -S
WARN [SPI_I2C] ms5611: no instance started (no device on bus?)
nsh> uorb top
e[0Jupdate: 1s, num topics: 114
TOPIC NAME INST #SUB RATE #Q SIZE
…
sensor_accel 0 5 401 8 48
sensor_accel 1 4 409 8 48
sensor_accel 2 4 409 8 48
sensor_baro 0 2 75 1 32
…
If any of you want to test anything on the board we could arrange a remote desktop session.
@proficnc Nothing else is connected now. Parameters are default. I guess if we can verify the autopilot hardware is the issue we will send if for RMA if you’ll have it since maybe we voided the warranty. I did not do the best job with the transparent plastic clips when opening the cube but was careful with the board and wore a antistatic wristband.
It looks like Copter 4.1.0 is on the board but I can’t imagine that 4.1.3 would make a difference. If the parameters have been reset and this error is coming up and other cubes seem fine then I think it is safe to assume that it is a hardware issue – namely the baro has been broken.
Here is the log prior to update. I enabled LOG_DISARMED, on 4.1.3, but did not get any log.
I think @rmackay9 was right. It looks like something is wrong when it comes to the second barometer. Autoanalysis of the above log says
Test: NaNs = FAIL - Found NaN in POS.RelOriginAlt Found NaN in CTUN.DSAlt
Test: Pitch/Roll = UNKNOWN - ‘BarAlt’
Later Edit: Autoanalysis of the second log shows the above lines so I do not know how relevant they are.
It’s on our to-do list to fixup the autoanalysis (it has fallen out of date) so I wouldn’t worry about that.
Each new version tends to have some additional safety checks so 4.1 complaining (even if 4.0.x did not) is probably a good thing. The new version is alerting you to a problem that would have otherwise gone unnoticed.
In the dev team we’ve discussed changing the error so it’s a pre-arm error instead of a startup error but it seems like it is a hardware issue so I think an RMA is in order.