LibrePilot Forum
Users => Vehicles - Helicopters => Topic started by: gongtao0607 on April 26, 2017, 09:11:32 pm
-
I'm a heli guy. However I'm not very satisfied with Vbar. There's certain part that definitely can be improved but they don't. Plus they are selling it way too expensive. I have a lot of used CC3Ds in my toolbox (from a previous quad project). I want to start a flybarless improvement for LibrePilot.
I'm currently a graduate student in computer science, embedded systems more specifically. I do all kinds of programming, but not the GUI part. I'll start improve it without changing the GUI and hope someone could help on that part. Anyway, the LibrePilot has a very good framework to start with.
The goal will be, to improve the LibrePilot on CC3D, make it a flybarless unit comparable to commercial products (let set bar here, VBAR). "Comparable" I mean in performance, User-friendliness will not be my goal, unfortunately.
I name it OBar for OpenBar, now. It's hosted in github
https://github.com/gongtao0607/LibrePilot (https://github.com/gongtao0607/LibrePilot)
The following will be organized as:
- 0. VBar parameters
- 1. VBar algorithm identification
- 2. VBar stick expo identification and mapping to Librepilot
- 3. Some implementation trash talk
0. VBar parameters
(https://forum.librepilot.org/index.php?action=dlattach;topic=3379.0;attach=6016)
(https://forum.librepilot.org/index.php?action=dlattach;topic=3379.0;attach=6018)
1. VBar algorithm identification
1.1 Tail algorithm
After several weeks experiment, I came up with this diagram to show the tail algorithm.
(https://forum.librepilot.org/index.php?action=dlattach;topic=3379.0;attach=6007)
Stick Input first goes to a yaw rate scaler(which set by the yaw rate). Then a Low Pass Filter, whose time constant is decided by "acceleration" parameter.
The filtered stick input then compare with gyro and feed to PI Controller. The PI Controller has P gain and I gain which sets separately, plus a gain scaler. The scaler has two sources: one is by an unknown fuzzy logic which has a gain range of 1.0 to 2.0; another is an input edge detector has a configurable gain between 1.0 to 2.0, only applies to the stick movement edge. On the other side, the stick input has a feedforward adds directly to the output. The gain is between 0-1 and can enable self-adjustment
Parameters:
assume the stick_input is [-1,1]:
Output = feedback + feedforward;
feedforward = control_loop/128 * yaw_rate/100 * stick_input;
feedback = pid_apply( stick_input * yaw_rate/100 * 500 - gyro );
P = gyro_gain/75 * P_gain/80 * 0.002;
I = gyro_gain/75 * I_gain/60 * 0.036;
Stop gain scaler = 1+stop_gain/100;
Explain:
100 in yaw_rate = 500 degree per second
30 in control_loop = 30/128 feedforward gain
75/80 P gain = 0.002 P gain
75/60 I gain = 0.036 I gain
50% Expo = 6 or 7 expo
20 Stop gain = 120% PI scaler during a stop (or acceleration)
All these parameters are all linear mapping (except the expo).
Remember the fuzzy logic can scale every gains up between 1.0x to 2.0x
1.2 Cyclic Algorithm:
Some new findings: the cyclic controller gain is related to stick input (like the virtual flybar fast flip algorithm) and also the current gyro reading.
Basically, larger stick = lower gain, faster movement = lower I gain and higher P gain. The relationship haven't be clearly found out. The major difficulty here is that the controller is not a pure PID controller. There's some conditioning in the controller and I am trying to figure out.
Some part of following might be wrong.
The control diagram:
(https://forum.librepilot.org/index.php?action=dlattach;topic=3379.0;attach=6011)
Parameters
assume the stick_input is [-1,1]:
Output = feedback + feedforward;
feedforward = stick_input*control_loop/60
feedback = pid_apply( stick_input*agility/120*150 - gyro )
P = gyro_gain/120 * 0.0008;
I = 180;
Explain
Feedforward gain: 60 in control_loop = 1.0 gain.
Agility scale: 120 in VBar Agility = 150 dps in LibrePilot (Yes this is very small, because feedforward gain is very large and here we only feed back very little portion of stick)
PI controller parameter:
P gain: seems from the gyro gain, but range is very small, like 0-8 maps to 0 to 120 in vbar
I gain: constant ~ 180
The style slider is a time delay (damping) at the PI controller output. I don't care that much so I just ignored it. It should give you the most "robotic" feel.
Paddle simulation: I haven't find any different behaviors yet.
2. VBar stick expo identification and mapping to Librepilot
Fortunately VBar cyclic expo and tail expo has the same algorithm. (I can't disable the integral on cyclic makes the analysis rather difficult)
On Vbar tail, one can set to rate mode and see the servo-stick response and analyze the expo:
The LibrePilot has a quite strange expo algorithm. I think the reason is the fastexp is not accurate. Here I list down the LibrePilot expo values, dumped from a running CC3D:
| Expo% | 25% | 50% | 75% |
| 0 | 25 | 50 | 75 |
| 1 | 25 | 50 | 75 |
| 2 | 23 | 48 | 73 |
| 3 | 21 | 46 | 72 |
| 4 | 19 | 45 | 70 |
| 5 | 18 | 43 | 68 |
| 6 | 16 | 41 | 67 |
| 7 | 14 | 40 | 65 |
| 8 | 12 | 38 | 64 |
| 9 | 12 | 36 | 62 |
| 10 | 11 | 34 | 60 |
The values are very different from a true EXP(), which makes me believe the expo value will be different for REVO or other targets
The VBar 50% expo is like 5% to 8%. I'll use 6.
The VBar 15% expo is like 1-2%. I'll use 2.
Some implementation trash talk
The functions currently missing in the LibrePilot I identified now are:
- Stick input setpoint weighting, self-learning (corresponding to the optimizer function in Vbar)
- Feedforwards: collective to tail, collective to elevator (precompensations in Vbar)
- Stop gain (or accel gain) (pitch pump, flight style, tail stop gain)
- Speed governor, with feedforwards (expert governor)
- Auto trim
This will be a long run. So the plan is important. The study part:
- Literature study. Understand the current flybarless algorithm(s)
- Blackbox analyze the VBar stabilizer algorithm, and clone to CC3D
- Blackbox analyze the stick response algorithm
- Combined analysis(Hopefully they aren't too complected)
The implementation part:
- Tune a baseline flyable helicopter (I have a TRex 450 DFC to do this), using original LibrePilot
- Cyclic and Tail (3-axis) algorithm implement
- Governor function implement, that requires some code structure change
- Add collective to stabilization axis, that requires a lot changes. I'm not sure by now if I am able to do that.
The algorithm
For a flybarless unit, the tail system (yaw) must be a rate PID, the Head Holding is just the I gain. However for cyclic, currently I identified two complete different algorithms.
1. like normal rate PID, need to tune PID numbers. Rate tracks the stick input.
2. like the one in the source code "virtual flybar". The gyro works like a weight stabilizer. Output = Stick_input + Stabilizer_correction*(1-Stick_input) //pseudo.
I'll try to do a blackbox analysis on the Vbar first to see what is used, and I will stick to that algorithm.
By a blackbox analysis I mean put it on a platform that can have controlled rotation by a program, and record the output.
The baseline helicopter
I mounted a CC3D Atom on my Align TRex 450 DFC. The mix and the radio have been setup correctly. I'm using a futaba 8fg + aftermarket sbus receiver. Currently working on tuning the PID numbers.
The problem now is my 450 wobbles horribly in ANY PID numbers (I tried turned down the P to 5). I've already had 3 crashes by the wobble, and changed all servos. I'm will try to figure out with the help of a pwm recorder (my BlackboxCC3D recorder).
Video uploaded:
https://www.youtube.com/watch?v=O2TPV3FJEdY (https://www.youtube.com/watch?v=O2TPV3FJEdY)
I removed the main blades and did a bench test. Seem a lot vibration from the gyro. I think I need to tune the gyro filter.
It turns out the actual problem is on the accelerometer. Under some vibration the accelerometer start to read everything completely wrong. I thought it is saturation but 16g scale still doesn't help. I tried just disable the accelerometer in attitude calculation, by reducing the Accel P and I (since we only run rate mode, plus the Vbar also only has gyroscope).
After removing the accelerometer fusion, the heli is now totally controllable. And I did a flip today! (no video).
I know I should tune those PID numbers now, but before that, I want to analyze a Vbar PID numbers.
My setup is like this:
- VbarSensor and 2 of CC3Ds are stick together. The Vbar output is the reference. One CC3D is the PID under tune. The other CC3D has my customized firmware (BlackboxCC3D). It records the gyro movements and the pwm signals.
- A servo whose arm is glued to the VbarSensor and 2 CC3Ds, so that the servo can drive the who thing in one axis.
- A arduino UNO to output 2 PWM signals. One to drive the servo, another as a receiver input to that axis, to both Vbar and the CC3D-under-tune
I used arduino the generate some standard pulse signal in order to help me analyze the algorithm used in Vbar
A video showing my bench blackbox analysis:
https://www.youtube.com/watch?v=ukirT1X-LHo (https://www.youtube.com/watch?v=ukirT1X-LHo)
(https://forum.librepilot.org/index.php?action=dlattach;topic=3379.0;attach=5836)
(https://forum.librepilot.org/index.php?action=dlattach;topic=3379.0;attach=5830)
CH1 is the platform servo signal (Y is the same movement recorded by a gyro)
CH2 is the stick input (same axis)
CH3 is the CC3D, PID need to be tuned
CH4 is the VBar response
Vbar default settings at aileron stabilizer has a equivalent PID = [0, 0.0275, 0]
Next step is to figure out the stick input to servo relationship
The CC3D response (the smooth one) to the stick is understandable. The response is the integral of the stick. However Vbar's is strange. I guess the model Vbar is using is:
output = (weight1)gyro_integral + (weight2)stick_input (Incorrect)
I'm still working it out. It seems a non-continues algorithm (if-else included).
(https://forum.librepilot.org/index.php?action=dlattach;topic=3379.0;attach=5838)
Snapshot included, CH1 is external movement, CH2 is stick input, CH4 is Vbar output
I also believed the expo disturbed me. Tonight I'm going to disable the expo to test again.
Just learned this process is called system identification, and matlab has such automatic function provided. I'll try look into details.
I think I almost there for mimicking vbar's algorithm. Look at the bench test result: identical! CH3 is CC3D, CH4 is Vbar for reference
(https://forum.librepilot.org/index.php?action=dlattach;topic=3379.0;attach=5860)
Pseudo algorithm
PID.iAccumulator * = decay_alpha
output = SetpointWeight * command + PIDApply( (1-SetpointWeight) * command, gyro )
decay_alpha is expf(-fakeDt/VbarTau), flybar_tau from my measurement is 2.5 (2.5 second time constant)
SetpointWeight is 0.45
(All default Vbar setting with all precompensation and expo removed)
The elevator: has a equivalent PID = [0.005, 0.0275, 0]
Sorry I made a mistake. The P=0.005 is way to high for a stable elevator, causing W-O-D.
I set to 0 and everything is just fine. The screencapture still shows the 0.005 one.
Very interesting finding. The small fluctuation from Vbar output, actually is not the P portion (I made mistake on this). But I don't know where its from for now. I'll leave it.
(https://forum.librepilot.org/index.php?action=dlattach;topic=3379.0;attach=5862)
The gyro low pass filter on vbar has an approximate Tau = 0.01 (LibrePilot fakeDt algorithm)
Next step I'll do the tail, which could be more difficult.
The vbar tail: has a equivalent PID = [0.0045, 0.07, 0] (In vbar: Gain=75, P Gain=80, I Gain=60)
The description at vbar software is very very confusing. It says 100 yaw rate = 1 pirouette per sec, which is ABSOLUTELY NOT TRUE.
From my measurements, 100 yaw rate approximately equal to 1000 degree per sec, and yes, vbar has a high expo setup. Half stick in vbar has a rate of ~360. So will be approximate 30% expo in LP
Maiden test flight here!
GyroTau = 0.01
Cyclic PID = [0, 0.0275, 0], rate = 360, flybar_tau = 2.5, Setpoint_weight = 45
Tail PID = [0, 0.0275, 0], rate = 360, Setpoint_weight = 20
https://www.youtube.com/watch?v=VMjfk51CcYk (https://www.youtube.com/watch?v=VMjfk51CcYk)
Second test flight.
Tail Tau fixed (I used 0 to disable decay, but didn't check, caused me to lose I completely).
Collective to Tail feedforward added.
I did some basic maneuvers: flips, inverted, tic-toc, half-piro-flip.
Watch me!
https://www.youtube.com/watch?v=3O4VYKfngno (https://www.youtube.com/watch?v=3O4VYKfngno)
The tail need more tune. I found one helpful article here:
https://www.rcgroups.com/forums/showthread.php?1538273-The-Heli-Gyro-as-a-Controller-Theory-and-Experiment (https://www.rcgroups.com/forums/showthread.php?1538273-The-Heli-Gyro-as-a-Controller-Theory-and-Experiment)
I implemented a low pass prefilter at the tail input, and I did a field test flight today. Here's the link.
https://www.youtube.com/watch?v=aAmgjQwyMJU (https://www.youtube.com/watch?v=aAmgjQwyMJU)
Tail is much better now. I also tried the built-in pirouette compensation. It's AWESOME!! Now I don't need to do that inside OBar!
The motor is not enough powerful, the Headspeed dropped a lot at full pitch(+-12.5). I'll reduce it to (+-10.5) (stock value for this heli) and test.
I have another 450L dominator which has more powerful setup. After I fine tune everything I'll work on that one.
Detailed vbar tail parameters blackbox(identification):
- Acceleration
- Stop gain
- Low pass filter (parameter not changeable)
Please find them circled out in the recording:
(https://forum.librepilot.org/index.php?action=dlattach;topic=3379.0;attach=5894)
After carefully thinking about the tail. I believe the vbar tail filter dsp is missed a bit, although solid.
Instead of doing Acceleration damping, stop gain overshooting, and low pass filter. I think we need to look back why these are needed. The reason is actually simple:
1. Gyro without I gain (rate gyro) is great, just no tail lock
2. Gyro with I gain has tail lock, but not good at acceleration and stop
The reason a HH gyro is not good at those, according to my understanding, is that the servo is slower than the setpoint input (user command) to PID. And such error quickly accumulate by I.
To avoid the issue. I am proposing a different filter algorithm. Basically we know there's limitation at the actuator, so we cap the command input.
1. Limited rate (the speed of the servo).
2. Limited acceleration (by the load on the tail).
3. No limited deceleration. (the servo should slow down immediately).
I will try my algorithm out later.
I need to ask my friends about this DSP stuff since I have no background at this. Meanwhile I'm working on change the architecture to incorporate the RPM input signal.
The idea was to alter the function of servo 6 output to be an input port, and reuse some of the pwm functions to also read the pwm period
Reusing servo 6 is cool, but use as pwm input might not be good. The pwm input channels are tightly coded into receiver. I think I need to make a separate module.
I tried to place it in the sensor module. Then I realized the CC3D doesn't even have sensor module enabled. This is awkward. I also try create a separate RPM module. However I think I'm not able to put another Task in CC3D. I might do some dirty coding and hope someone will replace it correctly.
The governor has another slight issue about the execution rate. The original thrust control runs a same rate as inner-loop which is 500hz. However when using a rpm sensor, each signal edge is way slower than 500Hz and most of the computing is wasted. Also a low pass filter need to incorporate with rpm signal. Because of the nature of the RPM signal, which is a set of pulse signal (is not a periodically sampled data), this can be difficult to achieve nicely.
About the stick response and expo settings. The LibrePilot has a weird fastexp algorithm I believe. I made a little expo cheat sheet sampled from the actual LibrePilot CC3D output:
Expo% 25 50 75
0 25 50 75
1 25 50 75
2 23 48 73
3 21 46 72
4 19 45 70
5 18 43 68
6 16 41 67
7 14 40 65
8 12 38 64
9 12 36 62
10 11 34 60
The Vbar 50% Expo at tail reads out: 16,37,68. Which is around 5%-8% in LibrePilot CC3D Expo
The result might be different from Revo because only CC3D uses fastexp()
I think I'm pretty successful for the prototype.
Other minor improvements:
1. Cyclic Ring
2. End-of-initialization servo twitch
3. Pitch curve fix (x-axis should start from -1, instead of 0)
Finishing:
1. Parameters (UAVO) cleanup
2. UAVO for state monitoring
3. Document for Heli (Almost done)
4. Document for OBar Module
5. Sample config and easy start instruction
6. Parameter range check
To be continued...
-
Step by step set up LibrePilot for heli
[NOT FINISHED]
Hardware page
Make sure you select the correct modes on the ports you will be using.
Receiver page
Setup receiver accordingly.
Set the min/max, neutral and direction. (Wizard or manual)
Neutral for the throttle should be right above the min a little bit. The others should be mid-stick. Increase the deadband if necessary. (I set to 5)
The (normal) direction should be:
Throttle: Low <-> High
Roll: Left <-> Right
Pitch: Push(Heads down) <-> Pull(Heads up)
Yaw: Left <-> Right
FlightMode: Doesn't matter
Collective: Negative <-> Positive
Set the "Flight Mode Switch" and "Stabilization Mode". (To use OBar, set all axes to OBar)
Set the arming stick
Vehicle page 1st time
Now we have to assign the output channel first.
In the vehicle page, go to helicopter tab, select a swashplate config, and assign channels at the left side. (Also the position of the elevator servo).
Select "Collective Pass through"
Deselect Link "Cyclic/Collective"
In the curve settings, set the right side curve to be 0 to 1 linear (instead of -1 to 1)
Output page
Set the update rate and mode first.
Set up the throttle output to a standard value (1100, 1940, neutral should be right above min). Do an ESC calibration by "Test outputs".
Set up tail servo travel (min, max). Min should be left-most and Max should be right-most. (If not, reverse)
About neutral: I suggest to set neutral as mathematical average of min and max, so that the left and right has same throw. This guarantees the two direction (CCW, CW) have same gain. Depends on the mechanical design, the neutral may or may not has an anti-torque angle, but it doesn't matter.
Set up swash plate servo: (I avoid to use the buggy Swashplate Leveling page)
1. Set the standard value (1100, 1940, 1520) and correct the direction
2. TX 0 collective and adjust the neutrals. (90 on the arms, a leveled swash plate, and 0 collective pitch)
3. TX full positive collective and adjust endpoints (level)
4. TX full negative collective and adjust endpoints (level). Make sure positive negative has same travel.
Vehicle page 2nd time
Basic settings:
Set Collective CCPM mix value to get +-12.5 collective pitch. Use a pitch gauge!
Set Cyclic CCPM mix value to get +-8 cyclic pitch.
Now you should have a correct mix setup.
Attitude page
Set the board rotation. You may find the following chart helpful:
(http://www.dronetrest.com/uploads/db5290/original/2X/c/cf8aa92f3d205893776f2cce2ca2bba69633197b.png)
Select "Zero gyros while arming" and "Wait until the board is steady" (I would)
Stabilization page
At Basic page:
Set the Expo as needed. Default vbar has 15% at cyclic and 50% at tail. The numbers are not equivalent. Put 7% at tail makes it similar.
Disable "Zero the integral when throttle is low" (Not mandatory)
Don't select "Update flight controller in real time" (Unless you know what you are doing)
Go to Advanced tab.
Select "Use Advanced Configuration View"
Set the "Rate mode response" 360, 360, 720 [check and fixme]
Set the "Max rate limit" larger
Set the Rate Stabilization PIDs: Roll,Pitch:[0, 0.0275, 0], Yaw:[0.0040, 0.040, 0]
Enable "Enable pirouette compensation"
Go to Expert tab.
"Gyro Noise Filtering": Set to 0.01
"Accel P" and "Accel I": Set to 0 to disable the accelerometer fusion. WARNING: don't use Attitude mode without accelerometer.
-
Place holder for OBar parameters explaination
-
Place holder for an OBar quick start
-
Welcome Gongtao!
This sounds like a very promising project.
There are some but not so many Heli people here. I am one of them really hooked on helis :)
Unfortunately don't do coding now a days.
From the video and what you say I would check if the main shaft and feathering shaft are still true and not even the slightest bent (since it suffered 3 crashes already).
If you post your UAV file I think some here can give you tips if the settings look okay or anything sticks out.
Good luck!
Karl
-
Hi Karla,
Thanks for the suggestion. I checked the shafts are good. But I read a lot of vibration from gyro. The heli was fine with Vbar, and I don't think I break anything except the servo gears. I'll try put Vbar back to see if it's a heli's problem. At the meantime I'll check the filter setting of the gyro.
-
Thanks for joining us. The heli crew here is small.
Vibes:
I start balancing my 250 cp helicopters with blades off. You might find imbalance in the head. Actually I start with the tail. And I use Audacity software and an old earbud (plugged up with glue--now a transducer)
-
If you need to reduce it further, go to the advanced page. You should be able to turn it down enough so that it doesn't do anything.
-
Thank you guys.
I start balancing my 250 cp helicopters with blades off. You might find imbalance in the head. Actually I start with the tail. And I use Audacity software and an old earbud (plugged up with glue--now a transducer)
The spectrum analyze can be really helpful. Audio tool is a very smart way. Vbar is good at this vibration, I think I should consider leave it now and see how good I can do in software.
If you need to reduce it further, go to the advanced page. You should be able to turn it down enough so that it doesn't do anything.
Yes I've already noticed that. Bench test is showing good result. I'm going to do test flight later.
-
Can I kindly ask how can I attach large image and place into the body?
-
For things like that, you can do Quote (reply with quote) to a post that does what you want, to see what the codes the other person used. :)
I recall for a large image, you first attach the image using "Attachments and other options" (at the bottom of the post edit page) and preview or post it, then right click the link for the image at the bottom of the post and "copy link location" (that is for firefox, something similar for other browsers) and modify the post to paste that link into the post where you want it as an "insert image".
-
For things like that, you can do Quote (reply with quote) to a post that does what you want, to see what the codes the other person used. :)
I recall for a large image, you first attach the image using "Attachments and other options" (at the bottom of the post edit page) and preview or post it, then right click the link for the image at the bottom of the post and "copy link location" (that is for firefox, something similar for other browsers) and modify the post to paste that link into the post where you want it as an "insert image".
Thanks. I managed to have them inserted.
-
Maiden flight has done.
Please find the video in original post
I feel same to Vbar, just slower(could be a slow headspeed)
Need more tune on tail.
-
Nice progress.
If you plan to contribute at some point, you should take a look here:
https://librepilot.atlassian.net/wiki/display/LPDOC/Git+Workflow
Not sure about the name...
OpenBar sound like "heavy drinker", is that compatible with heli pilot ? :)
-
Nice progress.
If you plan to contribute at some point, you should take a look here:
https://librepilot.atlassian.net/wiki/display/LPDOC/Git+Workflow
Not sure about the name...
OpenBar sound like "heavy drinker", is that compatible with heli pilot ? :)
Thanks, I'll read that later. Probably not gonna do that until all features implemented.
OpenBar :P didn't realize. Anyone may want to propose one?
-
Why not just continue and call it Vbar 2.0?
-
...Not sure about the name...
OpenBar sound like "heavy drinker", is that compatible with heli pilot ? :)
Thanks, I'll read that later. Probably not gonna do that until all features implemented.
OpenBar :P didn't realize. Anyone may want to propose one?
I think it's a nice joke, but to each his own. :)
-
I'm having issue adding more fields to the UAVObject.
The CC3D crashes at arming when adding a certain amount.
The CC3D completely resets and USB re-emulates.
Is it the limitation of CC3D? I definitely need to add more to UAVObject.
-
Try increasing PIOS_STABILIZATION_STACK_SIZE to 500
https://bitbucket.org/librepilot/librepilot/src/6b09e1a9dfbe0f1c60eae577b4dcd64234b2b507/flight/targets/boards/coptercontrol/firmware/inc/pios_config.h?at=next&fileviewer=file-view-default#pios_config.h-175
Culprit can be PIOS_SYSTEM_STACK_SIZE also.
Optimize using int8 where float are not needed also.
-
Try increasing PIOS_STABILIZATION_STACK_SIZE to 500
https://bitbucket.org/librepilot/librepilot/src/6b09e1a9dfbe0f1c60eae577b4dcd64234b2b507/flight/targets/boards/coptercontrol/firmware/inc/pios_config.h?at=next&fileviewer=file-view-default#pios_config.h-175
Culprit can be PIOS_SYSTEM_STACK_SIZE also.
Optimize using int8 where float are not needed also.
I realized to use DIAG_TASK to enable the stacksize count. The problem is now listed here.
1. After enable DIAG_TASK, the default PIOS_SYSTEM_STACK_SIZE 760 cannot even boot the system, until I enlarge to 900.
2. The task_info doesn't show stabilization, because that is a callbackscheduler
3. No matter how large I set PIOS_STABILIZATION_STACK_SIZE to (I tried 800), after arming, it shows a stack warning. I traced to the source code. callback stack overflow is the only place trigger the stack warning.
https://bitbucket.org/librepilot/librepilot/src/6b09e1a9dfbe0f1c60eae577b4dcd64234b2b507/flight/pios/common/pios_callbackscheduler.c?at=next&fileviewer=file-view-default#pios_callbackscheduler.c-381 (https://bitbucket.org/librepilot/librepilot/src/6b09e1a9dfbe0f1c60eae577b4dcd64234b2b507/flight/pios/common/pios_callbackscheduler.c?at=next&fileviewer=file-view-default#pios_callbackscheduler.c-381)
And line 429
Should I concern this?
-
After I disable the TxPID module, the stack warning gone.
Could it be the TxPID module not claiming enough size?
-
After I disable the TxPID module, the stack warning gone.
Could it be the TxPID module not claiming enough size?
It's likely. CC3D based on F103 has quite smaller SRAM compared to newer F303 or F405 targets. It might be the case that when you enable too many modules you run out of memory. I know for example that Autotune is not build on CC3D because of the memory limitation.
-
The baseline heli works out pretty good, but still a bit different.
Actually I learnt a lot in the past two weeks from old papers, recent papers, and mostly from a labmate who has a control background. I would like to test out some of the adaptive PID algorithms in the future. But now I just want to manually tune a "perfect" 450.
On one side, I recorded some sample data that can throw to matlab to estimate the physical model and do some simulation.
On the other side, I'm still trying to understand the algorithm inside vbar. As far as I can tell now, vbar uses a 2DOF PID algorithm plus saturation detection (anti-windup) plus some feedforwards at tail axis, I'll try figure out the parameters. (I think the same algorithm applies to other axes just need to adjust the numbers).
A 2DOF PID algorithm takes {kp,ki,kd,b,c}. My current guessing is that "b" is the control loop value in vbar; "c" is the flight style (robotic = high, smooth = low).
I'm still thinking (doing research) on how to automatically decide "b".
-
On the other side, I'm still trying to understand the algorithm inside vbar. As far as I can tell now, vbar uses a 2DOF PID algorithm plus saturation detection (anti-windup) plus some feedforwards at tail axis, I'll try figure out the parameters. (I think the same algorithm applies to other axes just need to adjust the numbers).
A 2DOF PID algorithm takes {kp,ki,kd,b,c}. My current guessing is that "b" is the control loop value in vbar; "c" is the flight style (robotic = high, smooth = low).
I'm still thinking (doing research) on how to automatically decide "b".
Personally I really prefer to fly with the Vbar stab mode but there is a lot of uncertainty to as to How it actually works, so I really love the research you are doing here!
-
Thanks everyone for supporting. I'm heading Texas for a summer internship. I don't think I will be able to do any flight there under 100F best sunshine. I'll try pack my blackbox platform there to continue do analysis, and maybe do some UI part programming.
The 450 experiment will continue after summer.
-
Hi gongtao0607,
Are you still working on this? I looked at the github repo, and it seems the most recent code is from last year. I'd love to pick it up some time, although perhaps on a bit more powerful hardware that the Atom.
Thanks,
—L.
-
I don't have a plan to continue now. Seems not many people interested gyros for heli anymore. I think the processing speed is not the issue (for Atom to run a 3-axis control algorithm), and the sensors are already enough for flybarless or even for rescue.
I realized I need much more control background knowledge and 3D maneuver practice to make a good flybarless unit. For now I don't have anything better than a normal PID tuned to a specific helicopter
If you are interested in making a flybarless controller. The blackbox I made may be helpful for you to analyze the control performance.