Micro Motor Community

NotFastEnuf E011 / Bwhoop Silverware Fork


#1388

It’s just a low pass filter applied to the motor output signals. Essentially smoothing out any rapidly changing signals.

What it does very well: creates a very clean “off throttle” response even with an imperfect tune. In other words, you punch out and chop throttle to 0… The quad idles down very quickly and cleanly even if some noise made it through the pid calculation.

What it does poorly: sometimes a rapidly changing motor signal is exactly what we want … Like in propwash or at the end of a flip or roll. Aggressive motor output filtering can make these moments have a little more bobble. Similar to the bobble you would see with one lazy brushed motor. So much of what we do is about increasing motor response… Torque boost, d term setpoint weights, throttle boost - a low pass filter on outputs is kind of against the grain. While low frequency changes are only delayed a tiny amount… Higher frequency changes are damped out and any immediate change that we want to have an abrupt edge becomes rou1nded off.

My thoughts, it’s a bandaid. Which is great when you need one…but I’d rather not need it in the first place. My brushless does not need it at all, and runs clean with one 1st order gyro pass and one 1st order D pass. But pids are much lower so noise is amplified much less. I’ve never been able to avoid it before on brushed because of the much higher pids. I did get close before using a second order gyro filter on my whoop instead of a first order …which is pretty similar to the cascading 1st order filters we are doing here… But I lacked the flexibility to really dial it in with 2 adjustable cuts which gives an opportunity to save a little latency and push P a little higher.

Hope a clear answer is in there somewhere.


#1389

In the mean time to get back in the swing of things… I’m gonna merge in my spi dma gyro code so that’s available for diy, try to add sbus telemetry or maybe just fport instead, ibus, crossfire, and smart audio. One thing is for sure, I have decided on an osd configurator. So that will take a huge restructuring from defines and is gonna make a compiled hex alot larger.


#1390

That’s great news! The only thing I miss from BetaFlight is OSD configuration.


#1392

hi, I have a problem with beecore lite v1 using bwhoop3 with nfe firmware and bwhoop profile selected, when the initial flight pitch roll and yaw are normal (easy to control) when a few seconds, and manuver yaw pitch roll is very difficult to control, what is the cause?


#1393

Are you now flying acro? Where you originally flying Angle/Level mode?


#1394

Angle mode sir,


#1395

Can you describe the problem more?


#1396

so, the problem is when I use the angle / level mode, at the beginning of flight control is very easy. but when it’s been flying a long time (about 20-40 seconds) the control is very difficult, especially in yaw roll and pitch. Sorry my English is so bad.


#1397

I guess I just don’t understand what you mean by difficult.

Most issues are vibration related. Check your props, check for bent shafts


#1398

for example, when I give full yaw but the rotation is very slow.


#1399

Any ideas on what might cause a quad to drift hard to the right/left but only after a few seconds of flying hard? If I fly inside in self-angle mode, the quad will fly really well and keep it’s level. If I take it outside, and give it a few full throttle punch outs…it wants to drift HARD to the right (or I have one that goes backwards hard). I’ve replaced every component except the FC and I have two FCs doing the same thing at present. I’ve tried different motors, frames, props…you name it.

Is there a setting Travis that can be used to maybe filter out acceleramoter errors like this?..or have these FCs just finally been crashed too much? :slight_smile:


#1400

Your situation sounds like vibration induced accelerometer drift. What props are you using? In all honesty I don’t think any amount of software filtering is gonna fix it… But I do have that new secret sauce gyro filtering code about ready. But it isn’t changing accelerometer filtering so I’m not super positive it’s gonna help. Try the technique where you pinch a motor can between 2 fingers and then blow into a prop to spin it up. Try to identify any out of spec vibration. Take a look at your camera mount setup and see if it could be transferring any vibration into your fc. Sounds like bent motor shafts to be honest… But for sure give the new code a shot when I upload it. Stay tuned here for updates


#1401

Just pushed up some changes for the DSM protocols. In order to maximize resolution for dsm2 and dsmx I had set a default scaling that required adjusting your transmitter stick scales to 150%. I am not changing this default because doing this gets the most out of spektrum’s protocols but it has come to my attention that there are a few radios that lack the ability to reach 150% stick scaling. I am not up to speed on many of Horizon’s products to list the exact models but have been told that some can only reach 125% and others only 100%. So I have re-worked the scaling code to accommodate a user being able to easily change the expected transmitter stick output scaling which the firmware is looking for.


If your DSM2 or DSMX transmitter can only reach 100 or 125 percent stick scale, then change the value of the define pictured above in rx_dsm to match the value which you are scaling to in your TX.


#1402

Next change is major…All beta filtering changes and notes for dual pass kalman/pt1 gyro filtering are pushed up to github and are the defaults now. Thanks to @las for helping to review code that pushed my comfort zone and being a sounding board helping to make the gyro code changes more readable. Set your board type, receiver type, any other preferred user settings - compile and flash.

Also updated are my most recent boss 7 pids and settings. I am eager to hear any/all feedback on how you guys think this is flying. I have tried a few different filter configurations out but nowhere near the amount of trial and error I usually put into publicly released settings. I already feel like its flying better but there may be even more gains to be had - so feel free to experiment… or just #sendit on whats here and tell me if you think it has gotten better. Have fun fellas!


#1403

Nice work @NotFastEnuf! Looks like you’ve been very busy behind the scenes.

Do you still suggest we use Torque Boost in the same manner with these new changes? I use it on everything but never strayed past 2.0 and lowering D by 60-70%


#1404

Yes, I would still suggest the same basic approach to torque boost. It’s adding something like D gain to the system so noise can accumulate quickly at high values. The higher you push it, the less D you need. Take a look at my most recent boss 7 tune as an example compared to some of my older brushed tunes. I am running a torque boost of 1 and D values very close to those of a whoop … Where it would have been much higher D Gaines than a whoop without torque boost before since the ducts of a whoop have a natural dampening effect reducing the need for D… Something I am very excited about though is that now with motor filtering off … The applied behavior of torque boost to the motors seems to be much more precise, with less bobble ending flips or rolls or in propwash scenarios. Torque boost generates a motor output that responds with a larger overall initial change on any rapidly changing motor signal … Motor filtering was trying to filter away any rapidly changing signal - they were not good friends. I still don’t recommend too much torque boost though. We want this feature to just ever so briefly “floor it” so that when a motor is commanded to change speeds … It can overcome change faster… But once the motor/prop moment of inertia is overcome… We want torque boost to back off and let the accuracy of our pid controller take over. Remember we are flying an error driven system - we can’t over amplify outputs. The right amount of torque boost is a fixed value that corresponds to the response time of a motor/prop to change it’s speed upon request. Lacking any advanced dead time calculations for our many available combos … We just have to guess. It’s a feature that’s a good fit for weak or over propped motors when used properly.


#1405

Thank you again for your awesome work and sharing it with us ! Flashing time !


#1406

Hi i got eo11 flashed it wont bind do you have config h setup for this i go xlight and mtx 9d module in it cheers


#1407

Did you change your target to e011 and rario protocol to bayang telemetry autobind? Is it an e011c?

Setting your board type and radio protocol are all that’s necessary to change in config.


#1408

How do you cange to eo11 and wats d8fference to the santa

Regards