There is no “resolution” if you get that error other than doing an RMA
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.
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!
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!
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
Platform- cube black
Boot loader id-???
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??
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
Hi Philip, I just plugged in a CubeBlack for the first time and Mission Planner flag it. I guess thats how I ended up here.
So I followed the instructions as above and My cudeblack fails to initialise as I get “Check Board_TYPE:Failed to init cude black - sensor” on my mission planner.
I don’t have log either
Contact your reseller
I got flagged for old cube which had pixhawk 2 written on it. Was unable to send the mail id and name via mission planner. It was working fine till now. updated to AC3.6.10 a week back.
There are a few things that could cause this that are unrelated to this Service Bulletin, but either way, replace it.
@philip I had a new cube black trip the SPI scan warning on the third reboot. I may have typoed the email box on the submit logs window. Would you like me to pm log files?
We have had some false positives on the SPI scan, but please RMA it anyway.
We are taking this as a zero tolerance to unnecessary risk.
When in doubt, swap it out.
I have an issue that seems to be related to this thread.
I’m using black cube pixhawk 2.1 that used to work properly, with the above Accels and Gyros ID parameters as mentioned, running flight controller firmware ArduCopter 3.5.7
The specific parameters checked as part of the drone assembly procedure, and it used to fly well with successful flights.
Since a few days ago, pre-arm checks don’t pass with massage: “3D Accel calibration needed”, here are parameters relates to accelerometer currently on the drone:
As you can see INS_ACC2_ID and INS_ACC3_ID are the same value, which means, as much as I know, the same internal Accel is in use - thus the third one does not exist anymore - am I right in this?
The mentioned facts lead me to think this issue relates this thread - does it?
What do you think? @philip