Micro Motor Community

NotFastEnuf E011 / Bwhoop Silverware Fork


BOSS6 Update using H8 props (at 8700’)

Ok decided to enable #define STICK_TRAVEL_CHECK
and I get blinking lights at every point except full right AIL. I tried adjusting it on the radio but to no avail. I haven’t noticed any difference in rotational speed clockwise vs ccw. How can I verify this?

Another thing: After returning craft from STICK_TRAVEL_CHECK to normal using the stick gestures, the gyro seemed whacked and I needed to unplug battery and replug for everything to work again.
The gyro seems a little more susceptible in general, but I also was using the WEAK filtering and otherwise everything else was nominal except for the level modes, which to me are far better than they were before (at least inside my living room)

Also lowered mix_throttle_increase_max to .5f with no noticeable difference as opposed to 1.0f. Must go fly outside to objectively verify this.


What board, e011? I’ll check mine again

That is truly strange. I did not get that on the zer0, e011, or beta lite


Actually I think you’re on to something with the confused gyro thing. There was previously an “on ground” flag in silverware which was clearing integral windup while we were disarmed … but that flag was lifted as soon as we armed. Hence the wind up in angle as soon as we started spinning props. I created and added the my own flag which is an “in air” flag cause that waits to clear until you’ve actually lifted off.

So the gist of what the code did before … if you were “on ground” - it squashed integral. I changed this to if you are “on ground” or NOT “in air” then -> if you are in angle mode… squash integral.

There is a chink in the armor here. If you are in NOT ANGLE MODE … integral never gets squashed. And we still need to squash integral whIle “on ground” for all other flight modes … but let it accumulate as soon as we arm. So I have anot her necessary bit of code to add!!! Easy fix

THANK YOU @chime13!!! This is what I’m talking about when I say I could not do this without you guys!!! Seriously! ! When you guys give me feedback … I do try to really think about it, recreate exactly your conditions, and try to find the possibility that something was missed. I should really change the name of my fork to micro motor community silverware!!! I love you guys - you are all making this so much better by participating! !

Will update you when fixed. If you’ve already tested this last flash - the symptom you’ll see is that error will accumulate while in acro and disarmed either through motion (if you move it around) or moving sticks and will cause you to fly off in a random direction when you arm. Doesn’t always seem to happen - but eventually it does. Funniest thing… I sat on the bench disarmed in acro and input pitch … as soon as I armed it flew off with roll to the side. Same axis reversal if I input roll. Flew off with a random pitch. I think this is a result of some yaw error accumulating and flagging the joelucid yawn fix which rotates errors with yaw input. But that’s just a guess. Lol


This is another reason I really want to get a serial interface up and running that allows basic setting changes on pc. Then we can have stable hex releases … and the “build your own” will be for beta testers.

I’d like to call all hands on deck for anyone with c programming knowledge to help with that! I’m trying but struggling. I need help!! :smile: Any takers?


Exactly! This is what happened to me on several occasions - I was able to eventually hover if I carefully moved the sticks to avoid rolling over and managed to get up in the air.


Nah, it will always be NFE’s fork. I’m just a beta-testing gremlin…at high altitude


Any thoughts on this?


Not currently, my 1 year old just underwent the obligatory right of passage into terrible 2’s where they successfully do the opposite of everything you try to keep them from doing and grabbed a hot burner on the stove. So I’ll be listening to screaming for the next 6 hours and not testing code. Sigh. Lightning fast fpv reflexes removed his hand so it was just a graze and isn’t serious … but he is not happy about it. My three year old pulled the same stunt last year with a heat gun in the garage. Sometimes I wonder how we’ve survived as a species. Our offspring are intent on destroying themselves. No other creatures in nature have to fight with their kids to keep them alive.


Gosh - I sure hope he’s ok!
I had several victims in the past too - My wife has once grabbed the wrong end of a hot soldering iron - after I said, “be careful with that, it’s hot”…
On more than one occasion, I’ve stuck my cast iron pan in the oven to finish off the meal, and later forgot that the pan was still oven hot, grabbing it like viking going for his axe, only to drop it like a little girl because it was over 300F…
The hand grew back , BTW - hahaha


Interesting! I think I might have seen this last night when I was testing, but I couldn’t put my finger on it… I shrugged that behavior off once I noticed what was causing a bad shudder in the air - a half-broken motor strut. The glue is drying on the bench now. It’s hard to diagnose two issues at once!

LOL, so true. Sorry about the kid - good luck calming him down! It is so hard for them to understand things at that age and reason with them - like that the pain is not permanent.


@chime13, @brianquad … little one has fallen asleep … thanks for your sympathy. He will be ok. It’s not serious but it’s not comfortable for him either. I was able to squeeze in 2 minutes in front of the pc and fixed the bug.

SAFE TO REFLASH!!! Thanks again for your help!

On to the next beta ideas which are within my wheelhouse of expertise. Let’s play with setpoint weight!! I personally think there is a bug in the current setpoint weight code. Go have a look if you want in pid.c - first off we are applying setpoint weight to the P term as per silver13’s design. And we create our pidputput for P by a combination of P based on error and P based on measurement (that balance is what you are weighting with the setpoint weight variables). Currently we have to stay very close to 1.0 which gives us pidoutput based on error mostly. But instead of adding in the P component of pidoutput from measurement … it is being subtracted. I think this is wrong. Mostly because if you use a very low setpoint weight … you loose almost all stick responsiveness.

Am I interpreting this wrong??? When based on measurement (setpoint =0) its like we are removing the stick component of P instead of basing P on it.

So I want to experiment with changing that sign or moving it to a different place in the line and adding the measurement component to see what that does. Then after I learn how the variables are behaving in silverware … let’s put a setpoint weight variable on the D term and see if that gives us any tuning or feel advantages. What do you guys think?


Sounds like a good idea -
I’d love to be able to choose between 2 set point settings by switch, since I really feel that set point weight has a lot more to do with feel than either rates or expo.

Will checkout the latest rev ASAP

Glad your boy is OK!


Eventually I agree … but I’m not happy with the setpoint weight code. Let’s make it awesome first … then put it on a switch.


Ok, I’m back!

Thumbs Up! - Your latest Rev no longer exhibits the gyro issue. Everything else works as expected. I gotta say, I kinda like the safeties - they keep me in check…


So I was interpreting it wrong. The sign change was merely to set the direction in which the 2nd half of setpoint was applied. To test/learn - I put the setpoint of yaw to zero so it was all the 2nd part of setpoint and tested making it positive… result was a constant spin. I made it negative and it was back with correct opposing stabilizing force. Sometimes you have to break stuff to learn how it works.

Also, with setpoint at 0, I learned that the craft is still self stabilizing - but it’s totally ignoring stick inputs. So this is a very useful setpoint exactly as silver13 designed it. I will explain why. Environmental forces imposed on the quad require much higher pid forces to correct. In fact if you tune to environment … you may be over tuned for stick inputs. So dropping this setpoint a little (just as I have since I first tuned silverware) has allowed for a sharp tune to resist environment while keeping stick inputs comfortable. Nice to finally understand why this worked the way it has.

So on to D term experimentation next…


D term experiment was a SUCCESS!!! Last night I was able to switch the D term calculation from measurement over to error and it flew like a dream!!! Very different feel IMHO. Somewhat predictive of my stick motions is how i would describe it. Which is sort of supported by the math. Including stick inputs in the D term calculation is the mathematical difference of D term based on error and one based on measurement (age old debate in quadcopter pid math) . The previous measurement type D term assumes that stick input is never changing. AND since D term is the first guy to show up at the party when your quad needs to move followed by P and then I … it makes since (to me anyway) that we need to let D know what the sticks are doing - and stick input is always changing. Now if you know pid controller theory, you understand why we often use a measurement based D term instead of error based… and I already talk your ears off here so I won’t go into it unless you ask. But the short story is that the issues it presents to use error are less applicable to brushed. So we get a pass.

What’s to come next…
I plan to keep both D terms and give you the chance to mix them with a setpoint weight variable for D. We already have one for P (we are the only firmware with one on P too) - and soon I will give you setpoint the on D term as well (just like betaflight). Then you guys can move your “hypothetical” slider between error and measurement to decide which “feel” you like best.

This (insert dramatic pause) is the beginning of a 2 degree of freedom PID controller for silverware!!!


I’m getting started with Silverware on a Beta Lite board.

Which version of Keil do I download? The MDK ARM version here or a different version?

Where are the settings for the Beta Lite FC? I know there is a .hex, but I want to mess around with the code, but from a decently configured starting settings (PID etc.).



@Imozeb Yes, that MDK ARM version is the correct one.

For the Beta Lite FC, the defaults in NFE’s fork of Silverware are the correct general settings (the “BWHOOP” FC selection).

Mostly, you’ll be editing the config.h and pid.c files (in Silverware/src/), if you want to make settings changes. Take a look at those files and see what you can glean from them!


Well, you’ve gotten me started down the rabbit hole of PID theory now - I’ve been reading up trying to figure out how setpoint weight works and I’m starting to get a handle on it. You figured out your P setpoint question before I could even figure that line out, but now I’m starting to catch up :- )

I see that Betaflight at one point had a P setpoint weight setting, but then removed it and now only gives the user the D term setpoint weight and transition settings. I haven’t yet found an explanation of why the P term setpoint weight setting was removed. People do agree that the D term setpoint it can really change the feel of the quad, so I’m interested to see how that makes a difference on our micro brushed builds.

If I read things correctly, it seems like Betaflight’s default is to calculate D term based on error rather than measurement (with a setpoint weight default of 1.0). And Silverware has been set up on measurement instead. I’m hesitant to ask you to talk my ear off (more for asking you to spend more of your time explaining things!), but you’ve gotten me interested by saying that the issues of using error are less applicable to brushed. That statement, together with my understanding that Betaflight’s default is to use error rather than measurement makes me curious for the answer! So, if you feel so inclined, please explain or maybe point me in the right direction (links?) so I can find out :- )


Only config.h now for a whoop. Universal whoop pids for any motor now exist and are set as default.

Welcome to the dark side!!! I Love It

This Is because betaflight is brushless firmware. With a 5" - the perfect pid tune for what you can do with your sticks requires higher pids than it takes to cleanly stabilize any environmental influences. The opposite is true of brushed. The perfect tune for stick feel and response is not enough to stabilize our micros from environmental influences. So we have to pass the perfect stick input pids and tune up higher to handle windy days. So P setpoint weight allows the pid controller to respond to the environment with the full high pids we set up, and stick commands only get (setpoint weight * pids) applied. Mathematically it is possible to configure a setpoint weight to lower stick input pids while giving full environmental pids but not the opposite due to the definitions of error (sticks minus gyro) and measurement (gyro alone).

Correct. Betaflight used to use measurement. But around 2.8 they switched to the option of which pid controller you wanted to use, then somewhere after 3.0 they wrapped them both into one with setpoint weight.

It’s basically because of D term kick resulting from setpoint changes being digital instead of analog. The derivative during a step up goes insane because the slope of a step at the step is straight up which leads to an insane derivative. Betaflight uses rc interpolation, also called smoothing, to take the steps out and make the digital input of stick commands look more analog. Brushless motors can respond to rapid changes in d at the stairsteps Because they have active braking. And they will cook from it. Brushed motors don’t care… we just need to properly filter the “noise” and we do just that. So we are ready to go error now too. Or a weighted blend of the two. Setpoint, for example, just means give me 40% of one calculating method, and 60% of the other, and then add the result. It’s just a type of offset average or a chef’s blend of the two. Lol.

Read this … especially towards the end. I had to re read it for a few days myself before it all sunk in and everything felt familiar enough (the variables and what they mean) for it all to click.
https://controlguru.com/pid-control-and-derivative-on-measurement/ So keep at it.
Then come back and ask questions. :smile: First hint … setpoint weight is a weighted blend of two things (one of them being the setpoint). Setpoint, within a pid equation, is the stick inputs. Don’t confuse the 2, they sound similar but are totally different. :):sunglasses: