RaceFlight One GPL violation drama, there might be more of that

Previous parts of this cycle are available here and here.

Betaflight community has a grudge against RaceFlight. And they have a reason. Two potential, or maybe I should say confirmed, GPL violations in one year is fully enough. That just does not looks good no matter how you look at it. This whole situation stinks. So it's not a surprise that what leaked as RaceFlight One source code is analyzed like crazy.

Latest news: RF1 code might have at least 2 potential license violations:

STMicroelectronics license violation

* @attention
*
* <h2><center>&copy; COPYRIGHT(c) 2016 STMicroelectronics</center></h2>
*
* Redistribution and use in source and binary forms, with or without modification,
* are permitted provided that the following conditions are met:
*   1. Redistributions of source code must retain the above copyright notice,
*      this list of conditions and the following disclaimer.
*   2. Redistributions in binary form must reproduce the above copyright notice,
*      this list of conditions and the following disclaimer in the documentation
*      and/or other materials provided with the distribution.
*   3. Neither the name of STMicroelectronics nor the names of its contributors
*      may be used to endorse or promote products derived from this software
*      without specific prior written permission.

If RaceFlight do not have an agreement with STMicroelectronics, point 2 is violated since bin is the only way RF1 is distributed

Atollic TrueSTUDIO(R) license violation

**  Environment : Atollic TrueSTUDIO(R)
**
**  Distribution: The file is distributed �as is,� without any warranty
**                of any kind.
**
**  (c)Copyright Atollic AB.
**  You may use this file as-is or modify it according to the needs of your
**  project. Distribution of this file (unmodified or modified) is not
**  permitted. Atollic AB permit registered Atollic TrueSTUDIO(R) users the
**  rights to distribute the assembled, compiled & linked contents of this
**  file as part of an application binary file, provided that it is built
**  using the Atollic TrueSTUDIO(R) toolchain.

One more time, if RF do not have separate agreement with Atollic, they are violating license above. I have not seen information that RF1 was built with Atollic TrueSTUDIO(R) toolchain.

I will leave it without any additional comment.

Read More

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

EXUAV Y120S drone racing frame: go home designer, you are drunk

Chinesium is amazing. Well, to be precise, not only chinesium manufacturers will do anything just to stand off a little. Just like this little (120mm) quadcopter frame called EXUAV Y120S. Why do I even bother to write about it? Simple: I love crazy designs. Just look at those pictures below:

EXUAV Y120S 120mm Mini racing frame

No, it’s not a tricopter. It is a quadcopter. But where is the 4th arm and where 4th motor goes? Below rear motor! It’s a Y with 2 motors on arms in the front and 2 motors on one arm in the back. Rear motors are counter-rotating! Continue reading “EXUAV Y120S drone racing frame: go home designer, you are drunk” »

Read More

iRangeX IR8M: when you clone too much, but that is not a bad thing after all

I love chinesium and admire chinese manufacturers very much for a simple fact: some time ago they stopped just cloning. They started to create new things based on “legit” ones. Just look at iRangeX iRX-IR8M 2.4G 8CH Multi-Protocol Transmitter.

iRangeX iRX-IR8M multiprotocol radio transmitter

Doesn’t this thing looks almost like Team Black Sheep Tango radio transmitter? Well, it is at least similar. But this is a bad thing? The way I see it, definitely not. It is similar on the outside, but it’s not the same. Just the way TBS Tango has similar shape to Sony PlayStation 3 DualShock controller. Continue reading “iRangeX IR8M: when you clone too much, but that is not a bad thing after all” »

Read More

INAV 1.8 is just around the corner

Next release of INAV, navigation enabled flight controller software, is almost here. INAV 1.8 RC1 has been released just 2 days ago. List of changes is rather long, so here is shortened version with the most important things:

  • STM32F1 boards like Naze and CC3D are no longer supported. INAV 1.7.3 is the last version that can used on those boards. All F1 users are encouraged to migrate to F3 or F4 boards
  • INAV is now able to get current time from GPS. Time is saved in blackbox logs and can be displayed on OSD
  • SmartAudio (TBS Unify Pro video transmitters) and TrampHV video transmitter support. When connected over free UART (TX pin only) and properly configured, band, channel and output power can be changed using OSD and CMS subsystem. Changing this over MSP and SmartPort on a OpenTX radio (Taranis, Taranis Q X7) with Betaflight LUA script is not tested yet and probably does not work (yet)
  • Receiver type is no longer selected using feature command. There is receiver_type CLI variable instead. Configurator handles this in transparent way
  • Multiple OSD changed. And by multiple, I really mean multiple. Not only is has better update rate but also takes less memory and less CPU time. On top of that, new OSD elements has been added as well:
    • Combined "On time"/"Fly time"
    • System messaged indicator showing additional modes information, arm failure reasons, navigation stages
    • Average cell voltage
    • New throttle indicator showing also throttle requested by navigation subsystem, not only by user
    • Time indicator
    • Heading graph indicator
    • VTX band and channel, required SmartAudio or TrampHV
    • Distance alarm
    • Negative altitude alarm
  • AUX channels have been remapped to RC channels. AUX 1 is now CH 5, AUX 2 is CH 6 and so on. Be careful when restoring rc map from dump!
  • Navigation modes override MOTOR_STOP. This solves the problem of motors shutting down in rare cases when Navigation modes were enebled
  • Several other changes and bugfixes

Read More

Bye bye Naze, we will not miss you that much

I have a news for all INAV pilots using Naze32, Flip32 and other boards compatible with NAZE target. You might call it a bad news, but reality is that it is not that bad and was long anticipated. It is official: INAV 1.7.2 was the last INAV release with NAZE target. That means the following: INAV 1.8 will not be available for Naze32, Flip32 and other boards compatible with that target.

You might was "why?". Quite simple: not enought flash memory, no way for new features to fit in. There was even not enought flash memory for bugfixes. And to be honest, I do not remember last time when NAZE users really got a new feature. Almost all new things were disabled for them. For more than a year, compiling NAZE target after adding something new was quite a challenge.

Does that mean that you can not use Nazes any more? Absolutely not. They are good boards and INAV 1.7.2 works on them just fine. You only will not be able to upgrade to INAV 1.8. And trust me, it is really worth it to invest in something better like F3 board. They are not that expensive after all…

By the way, CC3D is the next thing to be removed. Not yet, it still fits flash. Barely, but fits…

Read More

INAV 1.7.2 has been released

“Let’s do the news….” and INAV 1.7.2 has been released yesterday. Besides new targets (MATEKF405, Alienflight F7, SP Racing F3 NEO) there are few quite important changes:

  • ADC channel to function mapping is now configurable. Any ADC using function (battery voltage, current, RSSI) can be assigned to any ADC pin. You smoked Current pin? No problem, now you can use RSSI for that. It can be done using vbat_adc_channel, rssi_adc_channel, current_adc_channel, airspeed_adc_channel CLI commands
  • Support for analog pitot tubes, based on MPXV7002DP, known as APM Airspeed Sensor. It requires some hacking, but is pretty simple. I will publish detailed instructions in a next few days
  • Servo handling improvements:
    • servo min and max now do what they are supposed to be doing: output is scaled to reach them on max/min input, not just clip. And that means, that aileron differential is not super simple to archive
    • servo rule speed is now defined as 1 speed = 10 us/s. So, speed 100 means that full servo sweep will be done in 1 second. speed 50 means full servo sweep in 2 seconds and so on
    • smix min and max parameters were removed
  • Support for eLeReS receivers built into KFC flight controllers
  • Total flight statistics via stats, stats_total_time and stats_total_dist CLI commands
  • AnyFC F7 improvements:
    • buzzer on output #9
    • SD card detection is now configurable via sdcard_detect_inverted
    • support for external barometers using ANYFCF7_EXTERNAL_BARO target
  • Fixed wing landing after RTH that I already described here

Full list of changes is available here.

Read More

Pitot tube is coming to INAV

One of the things that INAV was missing, was a decent support for Pitot tubes, or more generally speaking, airspeed sensors. Autonomous flight, or landing, without knowledge about airspeed can easily lead to a stall. Stall can lead to crash. A crash leads to rebuild. Rebuild of big airplane is a nightmare. Although, for some time now INAV was able to use digital PX4 Airspeed Sensors (I2C, based on MS4525), but they are quite expensive and airspeed was only reported in blackbox logs. Not very useful, right?

Now, this is changing. Next release of INAV (1.8 probably) will bring at least support for much cheaper, analog, APM Airspeed Sensor based on MPXV7002 chip. Although some simple additional electronics (2 resistors to be precise) will be required, but this pitot tube should be available for all flight controllers with free ADC input (Current or RSSI). Fancy ADC remapping will allow to use any ADC without built in dividers (Vbat has dividers so can not be used) as pitot input.

mpxv7002 pitot tube for INAV

More than that, INAV 1.8 will (or at least should) bring PID scaling according to airspeed for fixed wings. This should result in better handling on both low and high speed.

mpxv7002 pitot tube for INAV

As you can see on the picture above, APM Airspeed Sensor is already installed on my small flying wing and is waiting for first flight tests this weekend. Logging only for now…

Read More

BLHeli_32, should I care?

Looks like BLHeli team is not wasting their time and is preparing something new for our multirotors. After BLHeli_S, we will also have BLHeli_32.

According to an announcement posted on RCGroups, new software for ESCs (and new ESC of course, since it will not be compatible with current Atmel and SiLabs MCU) will be:

  • Running 32-bit MCU, Cortex-M0 at 48MHz (STM32F0 ??). Which, in my opinion, is a very logical step to take. Please remember, that all SiLabs (Silicon Labs) MCU powering most of our ESC, are under the hood old Intels 8051. And please remember that Intel 8051 was created in 1980. 37 years ago…
  • There are few places where additional computational performance can be spent. For example:
    • Programmable PWM frequency up to 48kHz
    • Auto timing for better efficiency
    • Programmable brake on stop power, very useful for folding propellers
    • Voltage and current limiting
    • DShot1200
    • and more…

Airbot Wraith32 Plus

ESCs with BLHeli_32 are not available yet, but Airbot already announced Wraith32 Plus (with voltage and current limiting) and Wraith32 Mini (without voltage and current limiting).

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