[Jeuke26]

Hello dear dev team,

I know the cc3d and Revolution board are used for many applications but I don't doubt that the vast majority is for FPV use.

The Revolution F4 board has immense potential power in setup and quad control.

Multishot is available, extreme fast PID loop controllers and extreme low loop time itself.

So, as Raceflight is stable made for F4 boards and takes FPV to an entire new level in terms of performance and hardware, I would hate to leave Librepilot and I'm asking you guys when Librepilot will be in the same league using all of the potential power of its onboard components.

Thanks, I'm a loyal fan, using this ecosystem for a year now.

Philip

[Zallestial]

As far as using potential Im pretty sure that both openpilot and librepilot uses the full potential of a faster CPU on the board automatically. it doesn't work with "looptime" like cleanflight or raceflight but instead just works dynamically with triggers, the more CPU power it has to work with the faster it can react. Something like that.

as for multishot support I don't know.

[Jeuke26]

As far as using potential Im pretty sure that both openpilot and librepilot uses the full potential of a faster CPU on the board automatically. it doesn't work with "looptime" like cleanflight or raceflight but instead just works dynamically with triggers, the more CPU power it has to work with the faster it can react. Something like that.

as for multishot support I don't know.

I never used Cleanflight or Raceflight. But the latter was designed to take maximum performance of the F4 hardware. So wondering how Librepilot is dealing with the Revolutions increase in contrast to the original CC3D.

[TheOtherCliff]

(My personal opinions and not necessarily that of LP)

Everyone is welcome to try the many different firmwares that are freely available now days!  And to use which ever they like the best.

But by all means, please do your own testing and don't just take anyone's word that firmware X has feature X1 and so it must be better than firmware Y.  Sometimes it is true and has good scientific reasons behind it.  Sometimes it isn't true, but there are scientific sounding reasons given.  Often it is because someone says "I heard that firmware X is better."  The proper response to that is to ask "Why" until you get to the bottom of it.

An example is the race for faster and faster ESC protocols.  My "back of the envelope calculations" say that a human using hardware available (in the relevant future time frame) simply can't take advantage of the difference between OneShot125 and OneShot42, and by extension any protocol that is faster yet, but you should do the test yourself rather than believe me.  If you simply believe me I fear you would simply believe someone else making some other statement.  Without independent thought and testing, we fall into the trap of a critical mass of people believing the same thing "because everyone else believes it and argues for it" (kind of sounds like a contagion of political beliefs doesn't it).

The soon to be released version of LP has support for the OneShot protocols.  It also has automatic tuning that helps remove the human factor in tuning.

[TheOtherCliff]

There are some firmware features that make it have a different "feel" and even can make it more easily controlled; so given that the firmwares being tested have the same features...

One way to think about the question of what a human can actually use is to look at what a perfectly controlled (imaginary, perfect firmware), quad (made from current hardware or even made from hardware expected to be available in the next 5 years) can do when tuned to be the best that human (or generally any human) can respond to, then look at the difference between that "perfect" quad and what the firmware being tested can do.

Any firmware that has a deviation from this perfect firmware that is small enough to be humanly unnoticeable from the perfect firmware is by definition the best it needs to be, and further improvements to further reduce an unnoticeable deviation aren't very helpful.

I think that right now we're actually still at the stage of "I like this firmware better because it has these features that make it feel better" but we don't have a good list of all such features and we don't have a firmware that has all the features (including variations) in it.

[Jeuke26]

There are some firmware features that make it have a different "feel" and even can make it more easily controlled; so given that the firmwares being tested have the same features...

One way to think about the question of what a human can actually use is to look at what a perfectly controlled (imaginary, perfect firmware), quad (made from current hardware or even made from hardware expected to be available in the next 5 years) can do when tuned to be the best that human (or generally any human) can respond to, then look at the difference between that "perfect" quad and what the firmware being tested can do.

Any firmware that has a deviation from this perfect firmware that is small enough to be humanly unnoticeable from the perfect firmware is by definition the best it needs to be, and further improvements to further reduce an unnoticeable deviation aren't very helpful.

I think that right now we're actually still at the stage of "I like this firmware better because it has these features that make it feel better" but we don't have a good list of all such features and we don't have a firmware that has all the features (including variations) in it.

Well that's an extensive answer and thanks a lot for clearifying some statements.

The reason is asked is not because I "believe" other firmware is better, I just don't understand all the computer handling stuff that goes on in the flightcontroller.

The Revolution is a lot more performant FC compared to the previous cc3d and since Librepilot hasn't changed I don't know how it deals with it.

You are right that reactions of 125us is beyond human capabilities ( oneshot125 ) and Multishot ( like 25us or something ) is almost unreal but I read you need all programming to do yourself ( Cleanflight, Betaflight, racflight ) through CLI commands to "unlock" features and was wondering how Librepilot takes advantage of the performance upgrade of the revolution.

Does is do it automatically? Can you lower PID because the FC is faster? Is default PID already "most fly able" like in Raceflight almost no tuning is required because of taking advantage of the lot faster processor....

So again, I'm a Librepilot user but cannot deny other firmware and platforms. My knowledge just isn't far reaching enough to understand the difference. But you do know your stuff.

[ggrif]

There are some firmware features that make it have a different "feel" and even can make it more easily controlled; so given that the firmwares being tested have the same features...

One way to think about the question of what a human can actually use is to look at what a perfectly controlled (imaginary, perfect firmware), quad (made from current hardware or even made from hardware expected to be available in the next 5 years) can do when tuned to be the best that human (or generally any human) can respond to, then look at the difference between that "perfect" quad and what the firmware being tested can do.

Any firmware that has a deviation from this perfect firmware that is small enough to be humanly unnoticeable from the perfect firmware is by definition the best it needs to be, and further improvements to further reduce an unnoticeable deviation aren't very helpful.

I think that right now we're actually still at the stage of "I like this firmware better because it has these features that make it feel better" but we don't have a good list of all such features and we don't have a firmware that has all the features (including variations) in it.

Amen Cliff.

What he said.

[chromvis]

Does is do it automatically? Can you lower PID because the FC is faster? Is default PID already "most fly able" like in Raceflight almost no tuning is required because of taking advantage of the lot faster processor....

PID's are merely the coefficients correcting system response on the difference between desired and real copter position in 3 axis. They are interrelated and increase or decrease of them not necessarily lead to faster or slower response. In fact, just simple replacement of 20C to 30C battery (same otherwise) will lead to significant difference in copter behavior (or need retuning) simply because it has different weight.
I actually do not think it matters if revo processor is faster then CC3D. There is not much computing power spent on ESC control and reading gyros. at 433 MHz processor clock less than 1 KHz ESC refresh rate is eternity. More important that faster processor can handle GPS and other sensors.
I believe, CC3D is mainly used by racers - they lust need gyros and fast reaction , and it is cheap and fast to replace and set up, which is important, because of the way they crash.
It is all to personal preference and basic human nature to prize what they use over what they don't use.

[Mateusz]

I am not an expert, from what I understand so far (correct me if I am wrong):

- People desire lower loop-times to have freshest data from gyro. Despite that some design could in principle use analog gyro with higher sampling than common MPU (8kHz), I haven't seen such a design yet. So it's safe to assume that most hardware uses MPU or other digital gyro (8kHz at most). Then we do need filtering (some firmwares skip it to get even lower loop time). Filtering can also lower number of samples. How many samples (new information) are we left with ?

Is sampling the same thing over again, giving any benefit or just keeping CPU more busy with unnecessary calculations ? Till this point it makes probably sense to sample maybe at half of gyro rate ? Right ? But...

- Going further, my current understanding of PID controller is that it's a box, which takes two inputs:
a) what values sensors should read
b) what values gyro sensor actually read
then it converts that in controller into output that in turn changes the speed of motors. The change of altitude/position is the our process and can be affected by disturbances (i.e wind/vibrations etc..). Change of position thanks to motors, again affects sensors, and loop is closed. So it is crucial how fast mechanical component such as motor can change it's speed as it is a part of the whole system and compared to micro-controller (MCU) is slower. So can micro-second differences make any noticeable difference for human ?

- I read "Lower loop time gives you opportunity to tune you copter better". So if my copter is already well tuned, should I bother ? From what I read, is that people report no difference in PIDs after switching from OneShot125 to faster ESC/FC protocols. And if coefficients are close enough to best tune possible, but voltage level of my battery that changes while flying or total weight, make bigger difference to that tune than difference due to faster loop, should I bother ?

[Jeuke26]

Thanks all for contributing to this topic. The thing is there is A LOT of activity in the fast F4 type Flightcontrollers coupled with the fasted ESC ( F390 Silabs ) and high kv motors AND the use of new firmware like Raceflight and Betaflight ETC. Again, and to be informed well enough, hence addressing this here, is to understand the differences between what those firmware does differently given the same hardware setup compared to Librepilot ( of which I'm a very loyal user and know it by heart now ). You see all those different topics about all those settings, commands and possibilities that are not in Librepilot and asking if Librepilot behaves differently on a F4 ( Revolution ) board in practice than it did on the original CC3D and this compared to the other firmware options.

There isn't any change to the Librepilot version so wondering how others experience the revolutions potential with Librepilot. I'm not talking GPS and assisted flight but FPV racing. Would be nice to have a clear answer.

[liftbag]

Hi jeuke26.
As perhaps you know, I contribute to this project from day one (though very little lately), yet I don't believe that loyalty takes precedence over critical reasoning. Indeed, words like loyalty remind me of ancient OpenPilot flavors 

My experience with other flight software is reduced to dRonin and KISS fc.
While I don't feel the need to use dRonin rather than LibrePilot, I must say that KISS fc has something different.

Before proceeding with the discussion, I don't think that the mechanical and software latencies should be evaluated with respect to the human ability to perceive them, because it seems beyond doubt that we can not assess differences of hundreds of microseconds.
However, there are other aspects that surely escape the most, but which are well received by experienced pilots: responsiveness, locked-in feeling, the perfectly damped transition from full speed rotation to stop, and so on.
I must say that KISS fc embodies all of the above, and without any special setting tricks.

Onestly, I could not make a comparison with the same hardware, so my feelings may be due to two well chosen KISS equipped models. For example, I have the same perfectly tuned feeling with a revo equipped hex micro racer running librepilot.

But something tells me that KISS echosystem is able to write the corrections more quickly than OP/LP/TL/dRonin does.
I have noticed a peculiar behavior during the search of the perfect tuning. I use the OPTune method (my preferred). OPTune is based on research of UOV.
It's so easy to find the Unique Oscillation Value with LibrePilot, because the oscillations are slow enough to be clearly perceived and evaluated.
Since KISS fc is not easy to set up (or by far too easy, depends on point of view) because it seems little affected by PIDs changes, I tried to do it with OPTune method. And here I discovered that the oscillations due to a too high Proportional are actually a tremor, not distiguibile at the sight, and only barely audible.
I think this says a lot about the whole cycle speeds. But on this I would like the opinion of some of firmware expert.

If I try to think of an  high-latency error control system, I think that when the correction is written to the motors, the conditions may have changed too much, forcing the system to chase something that fails to reach, or to go instable causing small oscillations.
If on the contrary the system were zero latency, motors included (ideally), the exact correction would be implemented in real time, so less chance of unwanted oscillations or further corrections.
What I would say is that the search for reduced latency is right to be prosecuted because it undoubtedly brings benefits in the error control system (not directly in the vehicle control).
But I would say that recent extremes of raceflight I see more like a hype rather than real benefit.

[TheOtherCliff]

...

You are right that reactions of 125us is beyond human capabilities ( oneshot125 ) and Multishot ( like 25us or something ) is almost unreal but I read you need all programming to do yourself ( Cleanflight, Betaflight, racflight ) through CLI commands to "unlock" features and was wondering how Librepilot takes advantage of the performance upgrade of the revolution.

Does is do it automatically? Can you lower PID because the FC is faster? Is default PID already "most fly able" like in Raceflight almost no tuning is required because of taking advantage of the lot faster processor....

So again, I'm a Librepilot user but cannot deny other firmware and platforms. My knowledge just isn't far reaching enough to understand the difference.

Asking about the better hardware when going from CC3D to Revo making the firmware act better...  Once you get to a certain hardware level, any increases in processing power aren't detectable by the user.  CC3D is already good enough for that.  What we get from Revo is more features and room to grow by adding to the code where CC3D is already full.

Well, an analogy with computers.  If the DIR command in DOS lists the directory in the blink of an eye on a 386 processor at 66mhz, then what good is a 3.6ghz I-7 processor if all you do is the DOS DIR command?  The answer is that we now use an OS that has a GUI and many more features than DOS.

LP PIDs don't change when upgrading processor because they are based on physics units like degrees per second, not on loop times.  For instance our roll rate limits are set in degrees per second.  If you have it set to 400 degrees per second it works the same on CC3D as on Revo.  PIDs are also based on physics units.

[TheOtherCliff]

@liftbag

But something tells me that KISS echosystem is able to write the corrections more quickly than OP/LP/TL/dRonin does.

I haven't flown KISS FC, but from what you say, it's my guess that they have some feature so that you like the way it feels, better than other firmwares you have tried.  It's my understanding that KISS FC has a loop time of 1k, and if it is just that KISS handles the data faster, then using 4k on Raceflight should feel even better.

I think that getting these features that make it feel good is the biggest area that any firmware has for improvement.

[Jeuke26]

@liftbag

But something tells me that KISS echosystem is able to write the corrections more quickly than OP/LP/TL/dRonin does.

I haven't flown KISS FC, but from what you say, it's my guess that they have some feature so that you like the way it feels, better than other firmwares you have tried.  It's my understanding that KISS FC has a loop time of 1k, and if it is just that KISS handles the data faster, then using 4k on Raceflight should feel even better.

I think that getting these features that make it feel good is the biggest area that any firmware has for improvement.

First off, thanks all for contributing and by all means don't consider my question as anything but constructive and only an attempt to get members more aware of internal procedures to elaborate to me and others that don't have ( yet ) the same level of understanding.

Let me put my question in another way: what does another firmware ( let's take Betaflight and Raceflight as they are very popular ) different than Librepilot does? I have 3 quads with the cc3d and now one with the revolution all running Eclipse.

Is it really only a hype or does the other firmware take more advantage of the F4 type FC than Eclipse does and even if it means "faster than human reaction alterings"?

Don't forget not everybody has the same knowledge you.

[TheOtherCliff]

...
Let me put my question in another way: what does another firmware ( let's take Betaflight and Raceflight as they are very popular ) different than Librepilot does? I have 3 quads with the cc3d and now one with the revolution all running Eclipse.
...

LP / TauLabs / dRonin have modularized firmwares where it is easier to add any kind of new feature.  Different modules run as different tasks and wake up to run as needed and with priorities that mean the important stuff gets to run whenever it needs to.  Gyro task reads gyro data when it is available and writes it into a queue.  Some other task is set to wake up as soon as anything gets put in the gyro data queue.  At the other end, the ESC output task can be configured to wake up each time there is new data to send to the ESC or to wake up on a timer, every time the ESC can accept new data.

This is very similar to all the tasks that are running in a modern computer, but all that task switching does slow it down somewhat.

Other firmwares put all the code in a single big loop to avoid the delay and complexity of task switching.  This is a bit like single task DOS programs of old but it can run faster loop times.  There are many small devices today that still do this because it is the fastest way if you have a slow processor (the STM32 is not slow!) and only need to do one thing.  This single loop is a little bit of a straight jacket when you want to add something new.  It is more difficult to add a new "task" to this big loop because it must be called or at least tested once per loop, slowing down the loop for each and every thing you add.  You add a lot of things and it slows down appreciably.  It also limits how you can talk to your ESCs; once per loop.  You must slow the loop down (etc) so that it doesn't send to the ESC more often than the ESC protocol can accept.  That is one reason that other firmwares promote faster ESC protocols.

LP's task based approach can be configured to use a timer to output the ESC data smoothly at exactly the rate the ESC protocol desires or to output the ESC data synchronously for reduced jitter and lag.  LP allows the addition of things like scripting languages for complex autonomous control and sensors that need to run at widely different rates.  Personally, I like the idea of being able to add new things like these.

So another analogy.  Two cars to be driven on normal highways (or a race track if you prefer) where you will never, ever be able to go faster than 200mph.  One car can run 500mph.  The other can run 8000mph.  They both accelerate the same (to within the limits of human controlled testing), handle the same, same gas mileage.  Which do you want?  Now consider that the 500mph car has air conditioning at no power loss, GPS navigation, and a nice stereo; and the company producing it has plans for autonomous control.  Considering that these cars cost about $50 I say you should have at least one of each!