Micro Motor Community

NotFastEnuf E011 / Bwhoop Silverware Fork


SilverAG finished his Dual PID version. I just tried it and it works perfect including saving ability of both sets. Makes tuning better once again, perhaps you may want to port that to your fork…


it wasn’t always vectors, I used normal pids originally and acro yaw, but the yaw was fighting the pids at larger angles.

it turns out you have to apply it from the top in level mode


I loaded up the stick transition horizon mode to my fork with an adjustable transition point and full acro inverted behavior. Guys feel free to try it out. I’m actually not a fan of stick transition for the method but I couldn’t figure out how to translate GestG to angles of inclination. Maybe silver can help explain that to me when he has time.

The current fade out of level and fade in of acro is linear for both cases approaching the transition point. I tried an adjustable exponential fade on either one or both and it worked but just seemed to complicate things. I’d much rather just put the effort into getting a fade based on angle of inclination than tune a stick transition fade. Anyway it works well enough for whooping so it’s in for now. Keep the transition point high. I put in 0.7f for 70% stick as a pretry aggressive value to start … move that up if things get squirrely too fast.

I’ve only flown it on my rates and expo … i need to try it on more sane rates and no expo to see what it feels like there. I need to try level and racemode on different rates and expo too for that matter. If there is value to having more than one expo setting, I’ll create an aux feature for that too.

Also, @SirDomsen - I’ll get started merging in SilverAG’s work soon. Maybe right after a brief deviation into “whooverware” lol.


@NotFastEnuf I’d love to see you make “whooverware”. I tried to make one with silverware just by mapping the channels straight to the motors and then mixing the channels on my Devo 7e but there’s definitely a more elegant way to do it than that that I don’t have the skill for!


can you post a link to the code for horizon mode? The angle is obtained with atan2 function, but there are a few issues with it, for example with angles near 90 deg ( where tan function is infinite )


This is whats in there right now @silver13, but I’d like to gut that stick deflection based transition and replace it with a transition purely based on angle of inclination. I did that in my betaflight fork and it felt super smooth and very predictable. I don’t think its necessary to get to 90 degrees… in fact I’d like to transition to acro by 80 or 85 degrees inclination so its easy to get into a dive or knife edge. So deflection would become the absolute value of max inclination on either pitch or roll in degrees, and horizon_transition would then be about 80 degrees. And thank you as always for showing up to save the day. LOL


you might be able to use the stickvector function to get 2 vectors for, say, 60 deg and 80 deg and use those values to make up the acrofade variable

otherwise, I think sin( angle) = GestG[0], so you can make something like acrofade = map ( gestg[0], sin ( 60 ) , sin ( 80 ) , 0 , 1 )

but this might have problems with gimbal lock, my trigonometry is pretty rusty so I am not so sure if it will work or not


Just to make sure I understand GestG describes quad orientation based off of accelerometer data? If that’s true, can you tell me which direction [0,1, and 2] points?


In other words I’m trying to visualize this from imu.c for a better understanding of how to use GEstG[ ] properly to make qualifiers about the quads orientation.

Edit: This question can be disregarded completely if I can work out my question in the next post. Lol


So I tried
float inclination = fabsf (asinf (GEstG[ 0 ] ))
With tge intention of it being a variable that says … the quad is x degrees tilted off level right now
And tried putting a 0, 1, and 2 in the GEstG to return what the angle of inclination was relative to neutral … and it’s returning a value of 0 degrees tilted off level constantly. This is where I’m stuck. I need something that says … the quad is tilted x number of degrees right now which is calculated from gyro and accelerometer data.


the GestG vector is the vector combined from fusing the gyro and accel data, it’s like an accelerometer with a 1.0 value for 1 G


you can see the old way it was calculated, https://github.com/silver13/h8mini-dual/blob/master/H8mini_test/src/imu.c#L262

but it will give bad values when one axis is at 90 degrees


Thanks you @silver13, horizon mode is now successfully transitioning based off of angle of inclination instead of stick deflection. I just need to shove in some constraints so the transition angle can’t be set above say 85 degrees or so… and then fly it fpv to tune the transition exchange. I’m starting with a linear fade for both angle(fading out) and acro(fading in) between 0 and the user set transition variable. I may need some sort of exponential exchange though. My goal is to be able to smoothly push out of leveling and into a nose down dive that holds its attitude. Using the stick transition method for horizon it was to easy to overshoot looking straight down and over rotate past. Hopefully this will test fly better tomorrow.


Look at the values in debug mode though, while trying different orientations, I’m pretty sure weird things might happen in some situations.


Yeah that’s a good idea. I’ve actually tried to do that a few times now … but there is a strange mental condition associated with parenthood where brain capacity freezes the moment you have kids and any new knowledge you adsorb replaces something old instead of being just added in. A few weeks ago i was debugging looptime… then i had to learn things to pull off racemode in betaflight and horizon in silverware … and it seems part of how to use debug mode got the boot!!! Lmao!! The struggle is real! I swear!! :smile: I will get debug back in my headspace, just hope it replaces something meaningless when it comes back like this


@NotFastEnuf I’m 527 from rcgroups. I flashed your fork to my Beta Lite FC. All stock settings, except I changed to bwhoop hardware and turned on invert yaw pid (I fly reversed motor setup).

My quad completely freaks out as soon as I turn on my transmitter :joy: Feels like its doing max throttle and max yaw at the same time.



Max yaw usually indicates you need invert yaw PID but you’ve done that. Is your board set as a diamond in the quad, or square?Check that the gyro orientation is set the same as stock firmware.

Even then, the motors should not start at all by simply turning on the tx, I don’t think.

Does it work correctly with stock firmware?


It’s a 6mm whoop. It works fine with silvers branch of the firmware. Config is identical.

I’m pretty sure it’s a gcc compilation issue again… telemetry readings are also way off, it says my 1s is at 20V :joy:


Got it. It was the Kalman lpf filter. After removing that everything works fine.


Hmm, what filter did you put in its place? My beta fpv lite flight controller is still on the way for me to join in on testing but I’m quite curious on your results. I would not expect the kalman gyro filter to cause a quad to completely freak out as described unless it has something to do with gcc. Of course kalman is one of the experimental features so anything is possible.

Also congratulations on getting it worked out somehow! That’s great news!!!

I’ll be loading up even more experimental craziness later today. A much improved (in my opinion) horizon mode, improvements to racemode, and a racemode with horizon on roll instead of angle.