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

Preview: cheap APM Power Module for Cleanflight

Recently I’ve got my hands on a pair of cheap APM Power Modules from eBay with integrated 5V BEC and current meter (90A max). Although they are APM designed and will not work stright away with STM32 flight controllers like Naze/CC3D/SPRacingF3 (or rather would work only once since they are 5V scaled and those flight controllers require max 3.3V input) I have an intention to make them work!

So far, I’ve concluded that:

  • current measurement is done with Texas Instruments INA169 and 0.5Ohm shunt resistor
  • analog current out is 5V scaled, so probably 90A current flow results in 5V on meter output
  • voltage sensor output has 1/2 voltage divider. We can ignore it, most SMT32 flight controllers have voltage dividers (CC3D does not, but 1/2 is not enough in this case)
  • It more less works with a 1/2 voltage divider between current sensor and flight controller. Requires some tweaking, but something is measured. Will require scaling!
  • Integrated BEC works, and this is all I can tell about it I’m affraid

cheap apm power module for cleanflight

Read More

How to measure gyro noise frequency with Blackbox

Cleanflight / Betaflight / INAV lowpass filter tuning can be a hard thing to do if you have not idea what is noise frequency you want to cancel. Sure, you can blind test or read tutorials. But what if I tell you, you can measure it quite precisely using only Blackbox logs? Or measure rotation speed of motors? That would be nice, isn’t it? The only requirement are few seconds of Blackbox log with visible gyro (it can be also motor output or Pterm or even ACC reading) noise.

blackbox measure frequency 1

Continue reading “How to measure gyro noise frequency with Blackbox” »

Read More

Cleanflight low pass filters part 2

Quite a lot things changed in the world of low pass filtering since my previous port on this topic was published. So, here is the updated guide to Cleanflight LPF filters:

gyro_lpf

gyro_lpf is the most important low pass filter for gyroscope readouts. First of all, it is not part of Cleanflight, but is done by gyroscope itself. Cleanflight only initializes gyro with desired cutoff frequency. Allowed values are:

  • OFF
  • 188HZ
  • 98HZ
  • 42HZ
  • 20HZ
  • 10HZ

When OFF is selected, gyro offers fastest possible sampling rate (8kHz, new data every 125us) and smaller possible delay. But, it is extremely prone to any vibrations. Any noise from motor or propeller will be visible in gyro output. All other values of this filter allows gyro to provide new data every 1000us (1kHz).

42Hz is lowest 'flyable' cutoff frequency. It does not makes sense to go lower, since signal delay will be too big and filter will attenuate frequencies that are important from 'flight' point of view. So, 188Hz, 98Hz and 42Hz are the ones that are interesting for us. Exact value depends on propellers, motors, balancing, bearings state, frame rigidness and few other aspects. Let's say, that 250mm or smaller frames can use 188Hz, 450mm and bigger frames should use 98Hz or 42Hz.

gyro_soft_lpf

gyro_soft_lpf is a second state of gyro readout filtering before they are introduced to PID controller. One might ask: why two filters? After all, gyro_lpf does the same thing. Yes, it does the same thing. But using 2 LPFs in this case has some advantages. gyro_lpf can not be tuned. It's either: off, 188Hz, 98Hz, 42Hz. But what if, for example, main source of gyro noise is at about 90Hz? Cutoff at 98Hz would be pretty useless. One would have to use 42Hz, loosing a lot of usable frequencies and having to suffer from noticeable (from PID controller point of view) delay. This is why fully configurable second stage of LPF was added.

gyro_soft_lpf should be kept below gyro_lpf, and below frequency of main noise source. Usually between 50 and 100Hz. Frequencies below 50Hz are too important for stable flight to attenuate them. On the other hand, everything above 100Hz is useless and can be cut off.

pterm_cut_hz

This software LPF filter was removed and is no longer available.

dterm_cut_hz

Here, let me just quote my previous post:

(..) D term of PID controller, since it is trying to look into a future, can be a source of huge noise and vibrations. After all, looking into a future is always a tricky business. This is why D term can change with totally different frequency than gyro input and there is a very good reason to limit D term change. Too see how excess D noise can affect gyro traces take a look at my Blackbox tutorial.
(…) Rule of thumb is: smaller and more rigid frames allows for higher D term cutoff frequency and 42Hz is a good place to start. Bigger frames might require lower cutoff frequency and 10Hz is lower boundary.

If only frame and noise level allows, D term cutoff frequency should be kept as high as possible. This allows D term to reacts faster to changing flight conditions and can greatly improve UAV behavior in prop wash and rapid maneuvers.

Read More

DIY wireless telemetry link for UAV

Telemetry link between UAV (drone, airplane, boat) and laptop/mobile/ground station device can be very useful. Not only to get current drone position, altitude or battery level, but also, when wireless link provides such a possibility, to update drone parameters in-flight. Some radio links, like OpenLRS provides such a possibility out of the box. They include transparent serial bridge and almost any kind of device can use it to communicate with flight controller. Unfortunately, most RC radio systems lacks this functionality and additional telemetry links have to be used. Like SiK Telemetry Radio or 3DR commercial version of it.

One can buy or one can build something by his own. Some time ago I’ve chosen the second way and decided to build my own wireless serial link to archive 2 way communication between drone and ground station software. My objectives were:

  • 433MHz since it is legal in my country
  • has to allow to use my phone with EZ-GUI, since I do not like to carry my notebook to an airfield
  • as cheap as possible

To satisfy those objectives I’ve decided as follows:

Continue reading “DIY wireless telemetry link for UAV” »

Read More

Connecting ultrasonic rangefinder (Sonar) to Cleanflight

Keeping constant altitude with a drone is not a trivial task. Specially, if drone is supposed to keep give altitude very precisely few meters above the ground. One of the reasons for it is difficulty of reading precise altitude. Barometer can drift when atmospheric pressure changes and can produce a lot of noise. GPS is very inaccurate when dealing with altitude. One of the options is to use some kind of rangefinder. Ultrasonic for example. Cleanflight and its derivatives supports exactly one kind of those: cheap HC-SR04 sonar. There are plans to integrate different sonars, but none of official builds supports it yet.

dav

Continue reading “Connecting ultrasonic rangefinder (Sonar) to Cleanflight” »

Read More