Thanks @sier! The encouragement helps especially since I carve all this time out of what would otherwise be sleep. Feels good to have the fork caught up. I immediately dove into another new pid controller inspired by conversation with joelucid. Unfortunately something is off in my implementation. It partially works and partially doesn’t. Lol. Fortunately he just did the same thing in betaflight according to the github email chain so maybe i can look there for guidance. The concept is a feed forward pid controller based off the error d term that we have been testing. He suggested that since error d is basically composed of two components (derivative of setpoint minus derivative of gyro) and that since derivative of setpoint pushes in the direction of stick commands (just like P but much faster to respond) … that the error d term pid controller has too much push in the direction of stick commands. His solution is to compare the value of setpoint derivative vs. P term and only keep the larger of the two in the pidsum while leaving d to be gyro (measurement) based and resisting all change on the craft. This also gives the advantage of using a different coefficient on setpoint derivative which can be tuned to provide the exact stick acceleration that we want. So the stick tracking part of the current error based D term we are currently testing gets removed from D and becomes a feed forward term as an alternate source of P. I love the concept. But my current attempt at implementation is spiking setpoint derivative both when sticks are moved fast (expected behavior) and also whenever the neutral point on a stick axis is touched or crossed (unexpected behavior). And it’s only working on roll and pitch. Lol. So i have a few bugs to work out. Any of you out there that are both pid controller theory experts and proficient at code??? Rofl. Feel free to jump in any time!! Hehehehe
Markus Gritsch has a pull request for new Feed Forward function, so you may not need to do all the work
@NotFastEnuf Thanks for pulling the latest and keeping things up-to-date!
I noticed something that looked odd when I was pulling the latest:
The changes to rx_nrf24_bayang_telemetry.c include moving the application of expo down a bit in the decodepacket() function, which matches what silverxxx did in the main branch, but it lost the surrounding “#ifndef DISABLE_EXPO”, so I think that define wouldn’t work for that protocol anymore. The other protocol files didn’t get this change.
It looks like silverxxx removed the “DISABLE_EXPO” define from his codebase and replaced it with a check for expo levels less than 0.01 in every protocol file.
Anyway, the NFE fork’s “DISABLE_EXPO” doesn’t look quite right in that protocol and that bit of expo code isn’t consistent between the different protocol files now.
I can take a stab at fixing it and make a pull request, but I’m not sure how you would like it to look (closer to silverxxx’s latest with removing DISABLE_EXPO or what) :- )
Nice catch! Something about that change didn’t sit right with me …guess I was rushing a bit too much. Thanks for the offer to help. I wondered about that, but didn’t notice where he changed the other protocols to match. I see what he was getting at now though. Guess I need to take a closer look at the main branch before we decide what to do. I assumedon’t at the time the checking if disable expo was not defined within the conditional to check expo values wouldn’t cause a problem … but it would if you were attempting to disable expo via that define and hadn’t zero’d the values. You have a good eye for this stuff @brianquad! We sure are lucky you’re participating here!
Don’t want you to think we forgot about you. Was thinking about your situation this morning. I have three changes I want you to make since you are not flying with fpv gear. Comment out the mix throttle increase max strength line, lower p gain on roll and pitch to 19.0, and drop d gain on roll and pitch by 1 point. That should smooth you out. Lower pids than defaults are required if you are not hauling a camera around. If that doesn’t do it, drop yaw P by about 3 points. Report back with your experience with these changes and good luck!
Great news for the feed forward experiment… markus g. from the rcgroups silverware community coded a masterpiece in the H101 repository that looks like the Mona Lisa compared to my finger painting. Rofl!!! So I be graciously borrowing his and joelucid’s work for our benefit! While I’m there I will also grab vbat pid compensation! More good stuff to play with coming soon!!!
@NotFastEnuf - on your latest rev 15hrs ago - are there any additional changes that would change the behavior as compared to the previous build version? In other words, other than plugging in my default values, is there anything else I should be aware of? Everything that was implemented on your last build worked great and I don’t want to change any part of that…
I told you that three hours ago!
No its mostly just optimizations, some brushless features with dshot dma, rgb led dma stuff, some variable renaming, that kind of thing. A lot of the changes silver had made actually seem to be inspired by our work in this fork - so you can all feel proud that you participated in the overall development of silverware as a whole! There is the transient windup protection thing which is new but it should only help flips/rolls end crisper. It’s on by default now. I also reduced the max mix increase throttle strength default to .2f from our previous experiment of 1.0f. I still believe 1.0f is a good setting for a whoop bit many of you don’t use this fork on whoops and it was generating a lot of support issues to have it at 1.0f since it’s not obvious or intuitive to change it based on build type. Last change was use_multi is now the default instead of devo. It seems I must accept that taranis is the gold standard even though I’ll never put my devo down.
Hahaha, yeah you sure did didn’t you!!! Rofl. Cut a guy a little slack - I’m rolling on 3 hours sleep here!
Anyway, when I add it … it’s gonna be an option on the stick gesture channel just like error d term so we can do side by side comparison for a while. Early versions of my addition of this feature will also blink the led (or maybe buzz a beeper) when feed forward goes active to accelerate sticks so that we can have some feedback on tuning in the gain. This one is gonna need to be set just right to get full benefits. We want it to kick in on rapid stick movements, but go dormant on slow ones.
I recently migrated from T8SG to Devo 7E myself
Line 57 in
Silverware/src/drv_xn297.c seems to be missing a closing parenthesis
If you guys keep this up, I’m sure that Autotune is only a few lines away from being reality.
Then you can call it Silver-Cher
Seriously though, real good stuff here
Oh I feel bad now. I should have wrote that I’m planning FPV setup. Today I’ve received camera and mounted it already. I’m still testing with MIX_THROTTLE_INCREASE_MAX 0.2f and it flies great ! Also autobind feature works great. I’m very happy now need to train more. Thanks for all your support.
I tried your suggestions and my 8.5motor with hv lipos is more controllable now!
Hey guys. Very sorry to hijack this thread. Could I please request @NotFastEnuf to PM me? As a new user I can’t PM! TIA.
OK OK OK (picturing Joe Pesci in Lethal Weapon)… Another 3am late night session. @brianquad I knocked out all those changes to radio protocols and expo. @sier I got that close parenthesis - thank you and good catch! @chime13 - I was wrong about transient windup protection … I had not pushed that change in yesterday… it seems I added it locally but then got distracted with feed forward and it never made it up. LOL I really need to start sleeping more. But there will be time for that later …
For tonight!!! We have Transient Windup Protection and the Feed Forward Pid Controller!!! All changes pushed up and seem to be compiling fine. I put feed forward on our stick gesture test channel thing. I really want to fly it side by side with our “legacy” pid controller. Here is a secret for those of you that want to fly it side by side with the error based D term (@chime13 hint hint), a well placed ! to reverse the aux in pid.c for the d term and defining both features in config will put error on one side and feed forward on the other. But I digress… what is important to all of us is that we need to tune feed forward! So I have added a line of code that will flash the led when feed forward is working its magic. We want that led to flash on sharp stick inputs but not on soft ones (at least that’s what I think we want). I have a feeling that the default value is too low to kick in on a brushed whoop … so I will be interested to see what you come up with. Or you can just wait a few days for me to sort it all out… but either way it’s there if you’d like to try. This should be a lot of fun and hopefully produces that amazing sharpness of error based D term when we need it, but also stays nice and juicy when we want to flow. I really like measurement for that smooth flow, but I love the way error responds when I step up my game and get active on the sticks. If feed forward doesn’t magically give us both - then we will move on to a setpoint weight and stick transition like our betaflight brothers are rocking. Heck maybe we will even add it on top of feed forward. At this point I’m just rambling and thinking out loud. Don’t stress if the accumulating mass of options are starting to seem overwhelming. As always NFE defaults will reflect what I think the best setup is based on my own experience and feedback from those participating in testing. SLEEP NOW!
Just a few things I noticed I do on every quad:
- On the high leveling strength angle PIDs, you get really bad crash recovery. It just oscillates to death most of the time. Changing D term from 5.0 to 8.0 remedies this somewhat.
- And changing motor PWM from 32000 to 18000 gives a lot more punch
Nice, I see no harm in changing leveling D on the stronger set of leveling pids to 8. I’ll toss that in with the next update.
Pwm rate … I have had very mixed results personally on lower than 32k causing oscillations. Some of these tunes are tweaked right to the max for strong motors and hv packs. Had lots of reports come in too of similar experiences with lower pwm as well. This is the main reason I keep default at 32k. It just flies smoother and reduces the occurrence of support issues. I absolutely encourage messing with pwm rate to anyone in a tinkering mood though. Keep in mind there are also features like torque boost and throttle transient compensation to play with which are purpose built code for kicking out more power and are not on by default as well.
I too preferred lower PWM in general but also ran into oscillations within SW. I don’t have this issue with BF. I’m ok with it because performance has never been better.