Project Mockingbird: Getting your BF Whoop FC to Fly better than the Inductrix Angle Mode


#61

I like the sound of that!! After returning to betaflight to develop racemode … I had forgotten about that. Lol. It really is terrible. I say we fix it.
…and yes I understand it’s a safety and it’s there for a reason … cause accelerometers get a little confused after a good whack but I’ve never seen one take more than a second or two to get its head on straight. Besides … these are just whoops - no major safety risk for those blessed with a little common sense. Would you like that to go into mockingbird next?


#62

It would be my number one ask to add to any fork of Betaflight Angle mode. :grinning:

If you want to add it to Racemode first, I’m cool with that…I haven’t given it a try yet but looking forward to it.


#63

Just installed Racemod on my 716 build! Looking forward to testing it tomorrow!


#64

Crazy thought…could you link ACC OFF and ACC ON to DISARM and ARM to clear it out? Since I’m not using Calibrate ACC on Arm, what’s the need of having ACC on until you arm?

Good grief, if this can be solved, it will change the Whoop racing circuit as even the Inductrix based Whoops need a quick second sometimes to resolve. If this was instant…DAAAANG!


#65

I don’t think we can eliminate that second of confusion completely but it does seem realistic to improve the betaflight delay. The code averages an incoming sample of accelerometer data with old samples. We could clear the old samples … but the sensor itself still takes a second or so to settle down. We are getting in over my head a bit as far as current coding skills go … but the future is all about learning right! Anyway, from what I understand now, I’m guessing the best course of action is to completely gut the accelerometer code and replace it. The averaging thing probably is there to help with drift and anomalous readings in bigger crafts … and probably does its job quite well for them. Again another instance of betaflight not being written specifically for tiny brushed crafts. For a whoop we can probably use code that would be considered unadvisable on anything larger and get away with it. I’ll look into silverware next and see how the accelerometer is handled there for comparison. An honest assessment of performance in comparison would be fast recovery like an indy board but I’ve noticed it is sensitive to drift issues on larger non whoop builds. Should be just the example we need .


#66

How hard would it be to link acc_hardware as something we could get to in the adjustments tab or something like that? That way it would be most like an unplug…ha, even a switch to reset betaflight (like we do on OSD) would be faster than current…LOL


#67

Yes there seem to be a couple of different approaches that we could take. Turning the hardware on and off would essentially be clearing the old data being averaged in and help the sensor reset faster. But if you clear too early, you just turn it on with anomalous readings and still have to wait for the average to settle. It’s all just theory at this point. I personally like the idea of not having it go offline and also not preventing us from arming. Think about how a toy quad performs … you crash and if you try to take back off while the sensor is still scrambled - it blast off in a random direction. So you throttle slow … and if all looks well you’re back on your way. You never get locked out. Let’s make our change to betaflight to perform the same way. Lower the averaging sample so it can clear itself faster. As for the arming check … maybe there is a work around. What if we just add a motor stop aux command that we can use in place of disarming on a crash. The issue only happens when you disarm on a crash cause airmode is on right? What about a aux switch that just turns off airmode and kills throttle? Would that bypass the lockout? If so, then we just need the sensor to work past the garbage in averaging from the crash right? I really haven’t spent much time with betaflight and a accelerometer on other than programming racemode. And this trait also drove me nuts. What happens if you crash in angle with airmode off? Do you get forced to wait or does throttle remain active?


#68

You can do this simple test. Power on and don’t arm…then toss the whoop around, flip it, spin it and generally just shake it like mad. set it down and arm…nothing bad happens.

Now, fly for 1-2 seconds in Angle, land and disarm. then do the same tossing around. set it down and it will freak out.

I just did a test on my Eachine QX65 with OSD (actually not a bad whoop once you tweak it just a bit) and on a bad crash (while my wife would marshal me upright), I would disarm, go to the OSD menu select save and reboot and by the time I was upright it would be back and it would fly perfectly. THAT’s what I’m looking for…how do we zap the ACC and reboot.

If I had this quad at the Invitational, those 2 story falls would be happening and I’d be rebooting via OSD, so by the time i had settled or was marshalled, I’d be ready to go.


#69

I think this is a good start too.


#70

All very useful information. Hopefully I get somewhere with it! If not we will just have to find someone with more experience coding! Lol. But we’re gonna get it! I’ll do the test. It seems like that’s an indication that the solution should be more simple than anything I’ve been considering!


#71

Still I’m curious though … this is just an issue when you disarm right? What would happen of you didn’t disarm?
Are you disarming in a crash only because of airmode?
If so, why not put airmode on a switch and also couple that switch as a throttle kill in your transmitter? You could flip that switch to stop props in a crash… leaving that quad armed… and possibly take right back off??


#72

if you don’t disarm, you spin out of control into the ether…Disarming just let’s you drop where you are at so it can take time to settle.

I’ve had hard glancing blows that throw me out of whack and I don’t disarm, but fight the quad the whole time until 10 seconds later it catches up and settles. The best bet is to slow down and make small pitch/yaw/roll maneuvers so that it can get some good math again


#73

@NotFastEnuf hello everyone,
A question for you, i have been enjoying the wonders of Racemode on my E011 with your silverware fork, great work by the way, i love it, now i also have a beecore v2 that takes an omnibus target, i can’t seem to see any hex that matches on github, is there a chance a hex could be made for this FC?


#74

@Kahless Qapla bro!! (assuming you are the first Klingon emperor) :wink:

Omnibus has been added to the releases! Racemode is a bit more advanced on betaflight and much more adjustable… be sure to go over the readme and ask questions if you have any!


#75

Yeah man, when I’m not piloting a Bird of Prey I’m flying a Whoop!
I can’t thank you enough for taking the time to do that, i know you are a busy man.
Me and some others are very excited to give this a try.


#76

Hi!

It’s possible to have a compiled tarjet with RACEMODE for the CRAZYBEEFR in version 3.4 of betaflight!

I want racemode in my brushless whoop! Many thanks!


#77

There are two CRAZYBEEFR targets… which one is yours?


#78

Firstly I read that as CRAZYBEER. Secondly the two targets are for FRSKY and Flysky since the receivers are SPI connected. Apologies if I’m telling you what you already know.

CrazybeeF3FR = Crazybee F3 with Frsky rx
CrazybeeF3FS = Crazybee F3 with Flysky rx

I’m flying a happymodel snapper7 with the FRSky and would love to give racemode a bash.


#79

Hehe, I don’t follow betaflight that closely so I appreciate that explanation. And spi rx connection … that’s awesome. I have been out of the mainstream loop a while I guess. I’ll build your target too and let you know when it’s posted. Thanks


#80

No hurry (for me), more of a curiosity tinker thing to have a play with.