LibrePilot Forum
Development => Firmware General => Topic started by: lucas on December 28, 2015, 09:34:44 pm
-
I´ve read the threads of Betaflight and Raceflight over at RCG and seems like users are really pleased with how the Firmware behaves.
It seems to me like the biggest features of the FWs are Gyro Sync and low latency.
Are those things hard to code into the LibrePilot FW?
-
I´ve read the threads of Betaflight and Raceflight over at RCG and seems like users are really pleased with how the Firmware behaves.
It seems to me like the biggest features of the FWs are Gyro Sync and low latency.
Are those things hard to code into the LibrePilot FW?
Don't know how hard it can be, but developers are working to improve latency and gyro rate ;)
-
Thanks liftbag. Those are very good news
-
I think maybe not overcome.
LP now use OS in the firmware, Betaflight and Raceflight use while-loop structure, and can simply adjust the interrupt used for Gyro to improve performance.
Am I right, developers?
-
Yes.
These other firmwares use straight line code. There is no delay between one step and the next step
:begin
- wait for next gyro data at gyro rate
- read gyros
- calculate outputs
- write ESC (at gyro rate)
- goto begin
LP uses RTOS tasks that automatically determine which step needs to run next and wakes up that step. This allows an elegant way to handle ESC output modes that don't run at same rate as gyro.
- wake up and read gyros at gyro rate and write gyro queue
- wake up when gyro queue has data and calculate outputs
- wake up when ESC is ready for data and write ESC (may or may not be synchronized to "calculate outputs")
RTOS can take a small amount of time to see which task needs to wake up next and in preventing data from being modified while it is being used. We are working to minimize these delays.
-
The smoothness of Betaflight is due to this? I'm trying Betaflight on cc3d on my 250racer. Stock settings stock pid except 0,6 for rates yaw pitch roll.
My machine now flies incredibly smoother then LP but in LP i did the optune for PID so this is incredible!
The rc expo in BF is something I was not able to replicate in LP. Gives you so much smoothness without compromising the control of the multicopter while in LP I feel I loose the control.
Furthermore the air mode gives you control when you just cut the throttle to enter in the gate if you are a bit too high. Then when I suddenly apply the throttle it keeps going like it's on rails without strange behaviour due to not tuned pids.
-
These differences are the reason why more than one flightcontrols and Softwares existing...
Im flying the small racer with graupner gr18c FC, 8"prop cruiser with Librepilot and the next will be the big camera copter also flying Librepilot.
Maybe betaflight is the better choice for a racer or some special style...
-
It's pretty hard to subjectively compare relative performance of firmwares due to the huge variabilty in configurations and personal preferences. Flight performance may feel better to you, but someone else flying the same model will think it's poor.
For this reason, better to just avoid such comparisons. If you have something you like, then fly it.
-
Is cruise control active when inverted?
-
The default settings for CruiseControl have the motors reduce to 5% when inverted. This is to keep the motors spinning (quicker reaction than starting from stopped) and allow for continuing to roll to complete the flip.
FYI, Rattitude is difficult to keep inverted. If you hold about 75% roll stick it will be almost inverted. Some place between 75 and 85 it will go slightly past perfectly inverted and it will roll on past at full speed towards level. If you hold it there it will continue to flip as long as you hold it.
The combination of Rattitude and CruiseControl is very nice for learning to do flips.
-
The smoothness of Betaflight is due to this? I'm trying Betaflight on cc3d on my 250racer. Stock settings stock pid except 0,6 for rates yaw pitch roll.
My machine now flies incredibly smoother then LP but in LP i did the optune for PID so this is incredible!
Do you have any videos/ links / articles you can send me? i'm having trouble getting my cc3d/ betaflight copter in the air. successfully flashed betaflight with betaflight_CC3D_OPBL but now the copter won't fly.
Problems
1- I cannot access the ESC's via blheli when my hardwire connection is through the CC3D. I'm told this should be possible through betaflight. have you tried/ succeeded with this?
2- motors seem to not spin up properly, they just twitch for a while even at mid throttle. then at random they will spin up about 30 seconds later. I have done a basic esc reset and calibration but it didn't help.
3- The thing won't fly at all. i try to take up but it want to tip over immediately in both rate mode and horizon mode.
Notes
I've flashed the betaflight firmware .bin file through OpenPilot. i'm wondering if i need to flash the permanent .hex file to resolve my issues?
I just learned about librepilot and i'm thinking about using it due to all the isues i'm having with betaflight. But from all the great things i hear about betaflight and all the response gains you get at low throttle, i really would like to have that available!
My experience level is 6 months with quadcopters, 2 years with collective pitch electric helis, 4 years with nitro truggys.
-
quiljw01
ive had the same result with the beta flight , race flight and clean flight,
ill have one motor that will go crazy and the others will just twich, used bl heli suite to program esc's
ill even have smooth start up all the way to full, with the motor slider in beta flight ect , but when i arm it
and try to spin up motors one always goes crazy , if i re flash again and repeat procedure it will be a
different motor that goes crazy tried every mode, went back to libra pilot everything flys great ,
tried on an cc3d atom and regular
im just trying to figure out all the modes, low level , rate trainer, ect
-
So whats the roadmap for LP? My first ever brushless quad (Eachine Racer 250) came with a CC3D. I really wanted to play with LED support and Blackbox so I ponied up for a Dodo to slap into it. However, I find myself missing CC3D and LP. When it worked, I absolutely loved the GCS interface. I like the approach of the larger sliders for noobs which directly translate into PID adjustments on the expert pages, etc. Pretty much everything had floating tool tips and I understood what I was reading day one.
Anyway, what sort of Telemetry can we get out of a CC3D? I was using a sat reciever when I first got my quad and switched over to CF and at the same time a proper reciever (X4R) so I have no idea what sort of metrics we can read.
With all the tuning issues I've been having on the CF boards I sorta miss the performance I got day one with my CC3D. I'll probably get a Blackout frame and build that up with the Dodo and put my Eachine back to the way it was or get a Revo or something. I really enjoyed running the CC3D on it. Anyway, what's on the horizon for LP? Whats the latest on CC3D hardware too?
-
CC3D development is pretty much dead because nothing more will fit.
If some new developer wants to slim it down (already been done, so getting more is not easy) or modularize it somehow, that would be very welcome (provided it doesn't make a lot more work for adding to Revo etc.). :)
Many users talk about wanting this or that for their CC3D, but the problem is that no one steps up. :(
-
I like my CC3Ds and appreciate what you did with 15.09.
But us users must understand that the CC3D is hindering development for the Revo and the Sparky2. There must have been a lot of man hours invested in bringing support back to the CC3D and a lot more in trying to make any new change fit inside of it.
I for one would agree if the CC3D was left behind.
If possible, it would be nice if the latest GCS that supported the CC3D could run side by side with the first GCS that doesn´t support it.
PS: I changed the name of the thread
-
I have been looking at the Revo for a while now but since I'm building a 250 racer it have felt a bit "too much". How would it be to keep around the cc3d as a barebone racing fc much like the naze32 6dof or kiss fc. And then the revo for every thing else? What i mean is stripping the cc3d of every thing gps and non race stuff?
-
...CC3D is hindering development for the Revo and the Sparky2. There must have been a lot of man hours invested in bringing support back to the CC3D and a lot more in trying to make any new change fit inside of it.
I for one would agree if the CC3D was left behind.
It doesn't really hinder development for other boards, it's just that new features can't be added to it.
I don't think there's any chance that cc3d support will be discontinued, part of the reason LP was formed was to add back the cc3d support.
-
I have been looking at the Revo for a while now but since I'm building a 250 racer it have felt a bit "too much". How would it be to keep around the cc3d as a barebone racing fc much like the naze32 6dof or kiss fc. And then the revo for every thing else? What i mean is stripping the cc3d of every thing gps and non race stuff?
It doesn't really hinder development for other boards, it's just that new features can't be added to it.
I don't think there's any chance that cc3d support will be discontinued, part of the reason LP was formed was to add back the cc3d support.
If I understand correctly that´s the "modularity" that TheOtherCliff is talking about... You can´t just add whatever new feature to the Revo or the Sparky2, let alone the Ground Control Station, and expect the CC3D will run without a problem.
-
If I understand correctly that´s the "modularity" that TheOtherCliff is talking about... You can´t just add whatever new feature to the Revo or the Sparky2, let alone the Ground Control Station, and expect the CC3D will run without a problem.
You can add new features to the Revo and Sparky2 without affecting the cc3d, that's not really a problem. If it was we wouldn't have all the advanced modes that only run on the revo/sparky2.
I don't speak for Cliff but what I think he was talking about was rewriting the code to allow disabling and enabling parts of the cc3d code through the gcs configuration page. For example, if the cc3d could only run 3 of 4 flight modes you wanted in it at a time you could pick which 3 were enabled through the gcs. This would be a lot of work to implement and would only work for relatively small additions, something like the gps and flight planning modes would still probably never work.
-
I have several cc3d and an atom lying around here. I bought them because I simply love that FC. But at some point I had to say good bye, as the Revo controller is simply a lot better, and now it is easy to get as a clone.
I think that the CC3D has it's place especially with racing quadcopters and easy, simple setup. It performs so well there. But actually I am flying the revo now on both quads, and testing the sparky2 is on my plan as well. Those controllers are simply better than a CC3D.
-
Hi guys, I am new to the forum and CC3D but not new in programming stabilization stuff.. I don't know if you realized, but I am desperately trying to get debugging working on my machine so I can start working on exactly that, lag, latency, whatever you call it. I think i know where the problem is but I haven't been able confirm any, cos I can't get the damn thing to debug..
Anyway I realized there is a lot, like between 0.1 and 0.4 secs of lag, which is unacceptable for my flying. The thing is that the lag is also in manual mode (I fly planes) which is bad! I know the processor is more then capable of crunching all the data, at an acceptional rate that is. This brings me to my point. I've been browsing the code and found this little comment
/**
* WARNING! This callback executes with critical flight control priority every
* time a gyroscope update happens do NOT put any time consuming calculations
* in this loop unless they really have to execute with every gyro update
*/
So how often is gyro updated? I know this can be crazy fast. Back in the days just when heli gyros came out and I started programming stabilization for my RC planes from scratch (now I am trying to port some the code here) I was (still am) processing gyro (main) cycle at 30Hz and I had the stablest plane around. There is no need to process any more often, it just doesn't make it any better. Use 50Hz at max, thats the rate servos are updated but highly doubt it would make any diff. Set the task priority at 30Hz and read the gyro data at the biginning of the cycle. Thats what I am trying to do but I can't get the thing to debug. Anyway, if anyone wants to help me out with it find my recent posts :)
So what is the update rate of the gyros?
Hope this is helpful info..
Cheers!