Getting started basics: Unclear firmware version to upload


Hi everyone,

I am new to this, everything that contains Ardupilot, Pixhawk family, PX4, Cube, Pixhauk 2.1 and so on. There is A LOT of different names that is a unclear mess for me.

I have built two drones, without any support. Based on DJI Naza V2. Performs well, but the oldest had a fly away crash due to nothing. A lot of other users experiencing the same. Some people claims it is fixed in V2 - but it is not. Lets leave that shit for something better!

I do know Arduino in general and Alexmos gimbal solutions and handle it well.

But getting started with Cube eats up my time completely. A lot of frustration while following manuals and almost nothing is precise - just follow like trial and error and hope for the aircraft will work.
This is not the wanted experience. I think all manuals can be removed. Google and Youtube (MAD RC) are a lot more all covering and educational.
For this price tag, I expected a lot more pack up - install - calibrate - successfully fly. Like DJI is. One program, one solution, one manual.

When did I meant to be informed that Mission Planner was made for Windows 7 and not for Windows 10? I did send a bit angry email to Philip Rowse when I was feeling this is just to much errors everywhere. If so, why should I believe any word about reliability of the Cube?

Philip Rowse did tell me that Win 10 is only way to go and this email informed me about this Cubepilot forum did exist.
Then I saw the major issue with the sensors. Come on, isn’t that alpha/beta-thing to test that all these fancy IMU-sensors actually work?

Okey, let stop complaining.

After I did buy a Win 10 licence and installed it.
Then I did not get why I could not connect. Tried everything.
But, on Youtube I did found that I was actually meant to install a firmware, or maybe a bootloader. Then I did come to this:

The errors here is two USB-id’s. Both is working. Why?
There are also an PX4 BL and CubeBlack BL. Why? I do not recognize the last one in any manual.

I tried to upload all four combinations. But all is accepted, put update is done does it say everytime except first time.
CubeBlack does not overwrite PX4 to be more clear. I do not know what I am doing.

How do I know what I would like to have?
Why there is one QGS and Mission Planner, what is compatible with what? And pros and cons about everything?
Think I want the new thing symbiOS, (right name?) Not NuttX and the other one. I do not know why.
Is there a massive FAQ anywhere?

I do not like to continue, I building up anything on something I maybe don’t want.

Also, look and the picture on the right handed side.The boatloader link name is not visible, until maximize whole window. Good to see if it is heli or copter being made. Just random distracting example “should not be” for me.

Hexcopter, Alexmos gimbal, Futaba radio. 5212 T-motors. T-motors ESC. Black cube and here 2.

Best regards, thanks for any help,
Sorry for being angry. But there is personal reasons of my not excising patience.


First of all, I’m glad you finally arrived at the right forum! Welcome!

To start with, there is no point comparing anything here with DJI, DJI is a private company with a huge amount of funding. They have all their own engineering teams inside their organisation and they follow the instructions of their boss, Mr Wang.

Ardupilot is a community group, it is a group of individuals that are all very passionate about unmanned aviation, and they contribute code freely on their own time. The setup instructions for the firmware can be found at

Mission planner and QGC are both ground station software that can assist you to setup and control your vehicle from your PC.

They are both written by members of the community, without a lot of support.

For example, Mission Planner is written primarily by Michael Oborne, who worked on it continuously for many years for just “donations” and the grand sum was about $2500 per year total!

So you are joining a community, not a corporate giant. This does mean more work, investigation, investment of time for you.

As far as the cost? Feel free to call cloudcap and ask how much a fully set up and configured Autopilot is and the training package for your support staff…

Please don’t insult the community by trying to undervalue the hundreds of thousands of hours of work by many thousands of people that you get in the firmware for free!!!


Let’s get you started…

Step one… read the Ardupilot manual.

You have a Cube Black, so you need CubeBlack code.

Oh, regarding the service bulletin. We have three… that’s 3 more than the NAZA… where is their service bulletin about their issues? And it’s a few thousand less than Boeing.

If this is all too much, your distributor will be happy to give a full refund.

Now let’s start on a clean sheet, read the manual, and no more grumpy messages, ok?

Philip Rowse

1 Like



I started as a DJI builder too. This stuff is much harder, you must put in time plus time then some time to learn about everything you put on your craft. Learn about logs, tuning, better building, mission planning commands. Just to start flying it can feel overwhelming. I also Bought the cube because of unexplained flight behavior from my DJI. I had a fly away with an S800 at a concert I was filming. Crashing that $3000 drone in the parking lot was the best thing that could have happened. My last fly away I posted the log and the cause was found by someone on this forum.

So, both DJI and Autopilot have had issues but I know why Autopilot had issues. That was a cracked propeller that flexed in flight.

It was frustrating for me too starting with the cube and I have sent Philip a less than friendly email too, to which I was wrong. Philip is here every day as a CEO, He spends hours helping us fix it all. It’s not like DJI it’s interactive. This stuff is a great challenge at times and not for everyone.

Right now, you may just want a copter but once that’s done you can look at Rover, VTOL or RTK. DJI won’t do that without charging us maximum$.

Start over, give it time, someone will help you.

1 Like

You have had the differences well explained.

But there is one more major difference that may take some getting used to.
Asking questions and having them answered.

You will find it consoling in your learning curve that there are places to ask questions and a whole lot of people ready and willing to help.


Thanks for calm and explaining answers.
I have calmed down a lot since last time. The idea of installing to my cheapest frame first did also made me more relaxed.

I will make one last comment, I hope it is objective:
The ease of getting started affects the overall interest in the community. Basics should be easy, advanced stuff should be challenging and exciting. That was my expectations since my distributor recommended The Cube.

I do not like to continue, I building up anything on something I maybe don’t want.

This quote was not properly understood I guess. It was supposed to mean: “I will not configure the software on a unwanted base, because the supposed reliability och functionality may be missing. I likely will even erase it when I know what I should had chosen from the very first beginning”.

I have a plan to repeat my questions, make every single one clear before I continue.

I will answer first two by myself:

Q1: I tried to upload all four combinations. But all is accepted, but update is done, does it say every time except first time.
CubeBlack does not overwrite PX4 to be more clear.

A1: Upload a plane firmware between every change. That erases the memory and the Mission Planner will get that you are uploading a different version then last time. Then you can go back to copter and upload another version if you like.

Q2: Is there a massive FAQ anywhere?

A2: Not sure if there is a FAQ, but a massive all covering manual for Ardupilot.
Here is were to start from the very first beginning:
Skip all instructions and links that is included in the Cube package. It will take you in wrong direction where there is no answers. After understanding the Ardupilot manual, now you know more about the structure and terminology. Then check the complementary manuals.

Q3: Why is there two USB-ID’s to chose while uploading the software?
0x26AC/0x0011 and

Answer is not found here:


Your last question was “why are 2 USB-ID’s found?” I have wondered this before too but the USB-ID has been found so I left it blank. Still a good question.
To the topic ?
I just read:
arducopter 3.6.10-rc2 is out please use 3.6.10 on your vehicles now


The reason for two IDs?
The old ID belongs to 3DROBOTICS, Ardupilot used this as a default for ages…

Now we have our own company ID… so we use that.


Got it, thanks!

Thank you for make it clear.

My guess was actually something completely else. So as long as it communicates there is no problem about the USB-ID’s.

Q4: How to know that I am running on Chibios?

A4: Open Mission Planner (MP), on the left-handed side, there is a lot of grey buttons. One of them is called “Messages”. Click on that one. Scroll down if needed and then you see what Chibios version that you are running on. If there is no Chibios, then you may find NuttX or something else in that list.

Q5: Chibios, I see a lot of recommendations about go to Chibios. But I can’t actually find the answer in any thread how to change OS.
My quess is that to operatingsystem is included, hidden in this file. The older one is NuttX and the newer is Chibios.True?

Referring to this:
In the page end there may be the answer:

Build Variants

For some types of flight boards multiple builds in separate directories are provided. For example, you can find a firmware suitable for a Pixhawk2.1 Cube in both the px4-v3 directory and the CubeBlack directory. These variants use different underlying RTOS code (NuttX and ChibiOS). As we move the project away from NuttX to ChibiOS the NuttX builds will be removed over time.

So, maybe both “old” and “new” link above is Chibios. Did NuttX had another kind of version name? Please provide an example just to “know what I am doing?”.
Is NuttX like this below?

Next question will be more exciting.


Yes, Nuttx started with PX4, but is depreciated now.

Load CubeBlack.

We no longer use the word Pixhawk either, just Cube


Hi Humpus,

glad to have you in this blog. I’d made the same experience as you. To become a new Cube user isn’t that easy! My decision to try a Cube instead of Naza M V2 was taken to go any further and being up to date.

The best way to get your copter flying is to follow the instruction on ARDUPILOT.ORG as Philip said earlier. Very important, before 1st take off, is the section “Tuning Process Instructions” AND as a Naza user, be careful to connect all motor to the desired channel of the Cube. There is a different numbering against your “old” FC! Please see the attached file.

Any further questions always welcome. Here are a lot of members you will get support from.


Sorry, forgotten the file. Her we are.Motor Anordnung und (929.8 KB)


Thank you philip!

No more starting questions for the moment.

Q6: I have a more like development question. It is maybe to off-topic and deserves a new thread. Based on what I have read, I think the triple IMU is not comparing the actual values to each other live. More like “If value is between these stop values, then the signal is valid and true to the aircrafts behavior.” "If IMU 1 is off value or not responding, go to IMU2. If IMU 2 is off value or not responding, go to IMU3. If IMU 3 is off value or not responding, go to IMU1 and so on.
I repeat, that above is my thought, not a fact.

I would let it go 3 circles between the IMU:s before blocking and then swap to manual mode and constant beeping if there is no other useful sensors that tells the aircraft is not moving.

If there is processing capacity, I would like that normal mode is collecting data from the three IMU:s all the time when no errors is found.
Maybe like this:

IMU1 40% off the reading is true.
IMU2 40% off the reading is true.
IMU3 20% of the reading is true.
This is added together and divided so it is an compatible value.

In backgrund:
Last 3 readings added together divided by 3 is the a base of failsafe value in each X, Y, Z for each sensor. Then all sensors got this failsafe value collected. If the value is more than 10% off for IMU1 compared to IMU 2 in any axis, if IMU3 agree by 75%. If so IMU1 will be turned and the value will be:

IMU1 0% off the reading is true.
IMU2 70% off the reading is true.
IMU3 30% of the reading is true.

And so on, for each IMU. More magins with IMU3 due to no vibrationinsulation.

And some nice piece of code that tries to turn IMU1 back live again if there is no failsafe reading found in 2 seconds. 3 IMU disabling accepted each flight and fault code.

Sorry for explaining in logics, I don’t know a good word for it. Is it anything like this today? If not any plans integrate?


Thanks you for highlighting about the motor position! I did see that it was something not very logical about it. I think it is a bit confusing when letters and numbers is mixed in also a different pattern. But, I do think it is just something to get used to. I will double check before take off attempt. Thank you for saving me motors and props!

I will start rebuild the aircraft with the Cube this weekend.


This question is best to investigate the EKF code in Ardupilot. It’s a very complicated area, and there is no simple answer to your question.

The code is open, it may pay to have a look.


As Philip said, the way sensor failure handling works in Ardupilot is a bit complex, but I can give you an idea of the basic logic.

Firstly, there are two general methods for dealing with failure among redundant sensors (multiple sensors of the same type): failover and consensus. In the failover method, only one sensor is used at a time, but if it is determined to be bad, the system starts using another sensor instead. In a system which uses consensus, all redundant sensor readings are compared to each other, and one is chosen to be truthful based on whether the other sensors agree.

Ardupilot uses the failover method. If a sensor such as an IMU stops working, the EKF state estimator will start using the next healthy IMU.

Ardupilot also has a way to deal with a sensor which is working, but is sending incorrect readings. The magical thing about EKF’s is that they can use sensors like GPS to determine the reliability of completely different sensors like IMUs. The Cube has three IMUs, so by default, there are actually three separate EKF state estimators running simultaneously. If the current EKF being used thinks that its state estimate is inaccurate because some sensors are disagreeing with each other, Ardupilot will switch to a different EKF. In this way, Ardupilot not only has failure handling for a dead sensor, but can also decide whether a sensor is reliable. EKF’s can also use this measure of reliability to apply weighting to sensor readings based on how trustworthy the sensor is. This is a robust way of providing the sort of intelligent sensor selection you imagined in your post.


Thank you for spending that time and made a good answer!
Cool! Sounds that the Cube is that I did look for, not even in future - it is today. Nice to hear!

Thank you Philip also!

1 Like

Awesome answer! Thanks! And spot on!


honestly i felt EXACTLY LIKE HAMPUS…LEFT DJI NAZA CAME TO THIS COMMUNITY no background other than a real private pilot license. when you go through the steps and the groups that are set up…its just gonna get better bro!! and there’s always someone willing to help, im in saudi arabia in the desert i still get someone to help,
well said philip i really appreciate your work

1 Like