RaceFlight One source code has been published and what does that mean

In the beginning of time, there was MultiWii and it was good. But then times moved on and 8bit ATmegas were end-of-line for flight control. So, Baseflight was created. In the beginning, it was supposed to be only a MultiWii port to support STM32f1 flight controllers in a for of Afroflight Naze. And it was good for a while. But the guy that was running this show turned out to be a prick and one of Baseflight developers forked everything and called it Cleanflight. One might want to say "Hail Hydra" but let's try to be serious here.

Anyhow, everything was great again. No pricks anywhere and Cleanflight was growing. People started to fork Cleanflight. Betaflight, INAV and Raceflight were created. No problems anywhere, one big happy family.

It did not take long for things to change. Someone decided that he can make money by making code closed-source and run only selected, sold by them hardware. It was RaceFlight by the way and this is a reason I'm not writing much about them. There real problem is that you just can not make an Open Source code under GPL license Closed Source just like that. It is virtually impossible since all commiters would have to agree to that. All of a few hundred. Good luck with that. INAV tried to change license once (and still be Open Source) and it failed. Few devs just said no. End of story.

Back to Raceflight. When in late 2016/early 2017 Raceflight went Closed Source. Some devs decided to check this and that, decompiled RF firmware and compared that with CF/BF. Surprise, surprise, decompiled code for gyro initialization looked exactly like in CF/BF. Raceflight was violating GPL license! They had no rights to close the code of Raceflight. Period. RF team defended themselves as they could but IIRC finally published source code for Raceflight (not RF One) like GPL required. Joshua Bardwell did a video on that topic you might want to watch BTW.

You might think this is the end of a story, but not. Raceflight announced RaceFlight One and claimed that RaceFlight One is 100% their doing, rewritten and does not contain absolutely no code from Baseflight/Cleanflight/Betaflight. So it does not fall into GPL at all. They were more less believed and most of pilots forgot about the whole thing.

Until yesterday. Because yesterday, Kalyn Doerr aka rs2k (one of creators on RF) published the full source code of Raceflight One on GitHub and posted something interesting on Facebook too:

(…) I don't want to say much publicly right now. I have kept quiet as I have been in fear for my safety for some time now. Over the last several months I have documented Preston Garrison's business dealings as he has tried to keep me away from the business. I have had no success in reasoning with him. I created it originally to share with the community and I have poured my lifeblood into it. It will not die here. I am RaceFlight.

Pretty scary, isn't it? Drama and stuff. But what happened is that RF One source code is on GitHub. Take it while it's fresh since it might be removed due to DMCA soon.

Let's leave the drama and see what mentioned Prestion aka proggod posted:

Well apparently Kalyn decided to release our code to the public without consent from me. I have no idea what his intentions are, or why he would decided to do this, last time I communicated him he was working on his home life. I can say he doesn't own the code, and it certainly can't be licensed as GPL, especially since he was not the only contributor to the code base. (…)

In other worlds "_I have no idea what happened but this code is private and GPL does not apply". Well… Betaflight community decided to check again an they found out something very interesting:

//TODO REwrite this better
char *ftoa(float x, char *floatString)
{
    int32_t value;
    char intString1[12];
    char intString2[12] = { 0, };
    char *decimalPoint = ".";
    uint8_t dpLocation;

//TODO REwrite this better is nothing strange. But, exactly the same ftoa implementation can be found in Cleanflight, Betaflight and INAV source code. And by exact, I mean exact. not similar. Exactly the same. It was committed by hydra in April 2014 under GPL license. And that means one thing: whole RaceFlight One is GPL. This is how GPL works. They did not rewrite it from the scratch, they took some elements of GPL code and continued from there. GPL is very intrusive license: if you use anything licensed under GPL, your whole project is automatically GPL too. Period.

I have no idea who is lying. But someone on the RaceFlight side is lying. Why? If you do not know why it's because of money. An old universal truth. And I suspect this whole thing might have legal repercussions and someone will meet someone in a court. Is that good? No idea. Bottom line is: RaceFlight One is violating GPL license of a code it was based on.

Ah, there is one more small thing. According to some RF/BF devs and users, Preston Garrison always stated that RF One is not using Kalman filtering. More, users were apparently banned from Slack for suggesting RF One was using Kalman filtering. Guess what… The published code suggests RaceFlight One is using Kalman filtering… Funny….

I will try to keep my eye on it and if I will keep you posted in case of any major developments (if any)…

Update #1

No, there is no Kalman filtering in RaceFlight One after all. All occurrences of Kalman filtering are commented out

Update #2

After all, there is a Kalman filter in RaceFlight One. The commented out code refers to multi-state Kalman filter. Method PafUpdate that is used for gyro filtering is 1-state Kalman filter. Thanks DigitalEntity for discovery

Follow up for 2017.12.07

Read More

And the most popular flight controller for INAV is…

Did you ever wondered what is the most popular flight controller? Hardware I mean. I can tell you 🙂 OK, maybe it will not be a full truth, since I have data only from INAV, but assuming that distribution for Betaflight and Cleanflight is similar, we might know what is happening…

Important, this is not the number of boards flashed with INAV, but rather number of times a board was connected to Configurator!

This counts TARGET software name, not retail name. For example, all clones of Naze32 will be counted as Naze32

Data was taken in June 2017, multiple connections during single user session are stored as single entry. Continue reading “And the most popular flight controller for INAV is…” »

Read More

FC Soft Mount With Adhesive Pads FTW!

I will not try to proof if you should soft mount a flight controller on a racing drone. I will only say, that few months ago I was against it, but lately I changed my mind. Stronger motors, stronger magnets, more torque, more speed and out of nowhere, incredible amount of noise can be fed into gyro signal. Sure, this is not required, but motors, ESCs and battery will thank you when you soft mount flight controller. Less, noise, less restrictive filtering required, lower signal delay, better flight performance.

In most places over internet you can find either a rubber standoff or double sided tape solution. Sure, that works, but there is something better. Dedicated, double sided adhesive, vibration dampening pads. There are many sources, and many names. I'm using Sekisui brand. Check ebay, Amazon, HobbyKing. Look for gyro pads, vibration pads, vibration dampening. I do not want to advertise any particular seller, so you are on your own here.

Sekisui adhesive gyro pads

Continue reading “FC Soft Mount With Adhesive Pads FTW!” »

Read More

Cleanflight is still dead…

When week ago Dominic Clifton replaced all Cleanflight source code with Betaflight, I’ve written than Cleanflight is dead. Few people agreed, few (including Dominic himself) stated that it was a good idea. Main argument was that Cleanflight needed F4/F7, Dshot, CMS support and so on. Yes, CF needed that. This is true. In theory, with that one move Cleanflight got everything what it need. But also lost all it’s uniqueness. Further narration wast that all those things that only CF had will be readded on top of Betaflight code.

One week later I repeat: that was a bad move and here are my arguments:

  • All Open Source projects exists only thanks to The Community. The bigger the community, the better. I did not participated in Cleanflight development much. Only few really minor pull request. I joined the hobby too late. Many developers worked on CF code for months, maybe even years. Not only Dominic. If someones arbitrary decission would just “erase” my contribution (in both code and know-how) I would be pretty pissed off. Really, there was a reason all those people participated in CF. Now, all their work that was not present in Betaflight, is gone. That is not encouraging.
  • The same goes for 3rd party apps like EZ-GUI. All of them lost CF compatibility over the night. Will they be willing to adopt to the changes?
  • I’m really not sure is reimplementation of Cleanflight specific features on top new code will be simple enough to be done in reasonable period of time
  • The biggest programming problem I see are resources. Betaflight is in very comfortable situation: it, more less, can ignore the fact that servo and motor outputs can not share the same timers. After all, who uses servos on mini quads? And CF is (was) not only about mini quads. What about airplanes? Are resources ready to handle servos and motors at the same time and prevent all potential clashes? I doubt it
  • Changing codebase maybe looked like a best solution to get F4, Dshot and so on. But was not the only way. Somehow INAV got it after all. And Betaflight got it. How? Thanks to The Community

Read More

Cleanflight is dead…

Only 5 weeks ago I’ve written that Cleanflight has a problem. Looks like, the problem was much bigger than I expected. Today in the morning, Dominic Clifton aka. Hydra essentially killed the project by resetting GitHub repository to Betaflight 3.1.

It was announced on Facebook:

Cleanflight v2.0.0-RC1 is out now, with all the new features from Betaflight v3.1 – please share this post!

Thanks to the hard-working betaflight developers especially Boris B, Jason Blackman and Martin Budden who have been doing fantastic work for us all!

Also, all GitHub Issues and Pull Requests were deleted.

What does that means? More less the following:

  1. Cleanflight lost all it’s uniqueness and is Betaflight under different name
  2. Pilots that were using Cleanflight on airplanes or big multirotors are left alone. Betaflight aims on mini-quads, not airplanes!
  3. Why anyone would want to use CF when BF is there and this moment it offers better community support?

The way I see it, it was a nice ride, but now it is over and Cleanflight is dead. Too bad, since it had a huge impact on multirotor community over last few year…

Read More

How to connect APM Power Meter to Cleanflight and INAV

This topic was eluding me for some time now. It’s time fix the problem and finally present a short tutorial how to connect 90A APM Power Meter for flight controller boards like Naza32, SP Racing F3 or any other running Cleanflight / Betaflight / INAV software and equipped with Current Meter ADC input.

I will not show where to connect APM Power Meter to flight controller, since this differs from board to board. Some boards have dedicated pins, on some boards PWM input pins are used for Current Meter ADC. You have to refer FC documentation and / or flight controller software documentation.

Continue reading “How to connect APM Power Meter to Cleanflight and INAV” »

Read More

Cleanflight, what is up with you?

Those are my personal thought on the topic. If you do not aggree, it is fine, I will not argue or discuss. You have a right you your oppinion, I have a right to mine…

When I entered multirotor hobby about 2 years ago, Cleanflight was The Flight Controller software to get. OpenPilot was about to die, just like BaseFlight. Or maybe even BaseFlight was already dead… never mind.

Bottom line was that Cleanflight was it: fast realease cycle, great support, great community. Everything was just better there.

Then, somewhere in second half of 2015 it started to change. You do not remember what happened in the second part of 2015? It is more less the time when both Betaflight and INAV (both are forks of Cleanflight just like Cleanflight was the fork of BaseFlight) started to appear. I remember narration behind both of those projects: we will rewrite some code, make it fly better with racers (Betaflight) and handle GPS better (INAV) and when this is done, it will be merged back to Cleanflight. Continue reading “Cleanflight, what is up with you?” »

Read More

PID looptime: why it is not only about frequency

Last 18 months was an extremely good period of time for all mini-quad enthusiasts. Progress, hardware and software both, was just incredible. Who could have guessed that in less than 2 years mini-quads will evolve into main group of drones with such excellent flight characteristics. Just take a look at looptime. When I entered the hobby, standard looptime was 3500us (285Hz). Then, someone noticed that mini-quads fly much better when looptime is lowered and it started. Right now, standard looptime is 2000us (500Hz), while Betaflight starts with 1000us (1kHz) or even 500us (2kHz) in case of faster flight controllers.

Just by looking at numbers one might come to a conclusion, that looptime should be kept as low as possible and higher control loop frequency is better. Hey, 2kHz should be twice as good as 1kHz, right? One might even thing that it’s really about frequency. Well, this is both false and true: sometimes it is not about frequency, sometimes it is about frequency after all.

Continue reading “PID looptime: why it is not only about frequency” »

Read More