Is a separate file for each target possible? So if you need to do some hardware changes outside of “standard settings”, you could just go to your_board_type file and change it there? Easy to find that way. Just a suggestion, might not be possible…
I think so with a little daisy chain. One header file that just includes all the target files in a #list, and that header file gets included in config to keep the top of config clean.
I Flashed a beecore lite with the intent of mounting it upside down.
As suggested I :
after the line: #define SENSOR_ROTATE_90_CW
And reassigned motors like this:
// MOTOR PINS
//#define MOTOR0_PIN_PB1 // motor 0 back-left
//#define MOTOR1_PIN_PA4 // motor 1 front-left
//#define MOTOR2_PIN_PA6 // motor 2 back-right
//#define MOTOR3_PIN_PA7 // motor 3 front-right
#define MOTOR0_PIN_PA6 // motor 0 back-left
#define MOTOR1_PIN_PA7 // motor 1 front-left
#define MOTOR2_PIN_PB1 // motor 2 back-right
#define MOTOR3_PIN_PA4 // motor 3 front-right
It fires up and the props are rotating in the right direction, but when throttle applied,
its spins like a top on the floor.
The motor reassignment seems to have worked, but maybe the gyro thinks its upside down?
Thanks very much for any insight!
Heres a link to the config.h
Which way are you spinning your props? Maybe #define INVERT_YAW_PID might have to be uncommented.
Good idea, but I am going for regular rotation and #define INVERT_YAW_PID is commented out.
If you can’t get it going, a pic showing the board position clearly and where each motor connects to the board would be needed to give useful help, otherwise it’s sort of a guessing game. Can be frustrating getting the motor order right, there’s 24 possible combinations.
Sorry, should have done that in the first place!
I originally (in the above posts) was swapping 0-2 & 1-3 motor positions.
I thought about it a little more and tried
swapping 1-2 & 0-3 which to me makes more sense…
Still flops over and spins like a top when armed. Motors are turning the correct direction and props are on the right way.
So my latest motor assignments were:
Thanks for your thoughts!
Motor 0 and motor 2 are the back motors.
0 2 ^viewed from top
Swap em like I told you for your pictured orientation. Then mess with gyro rotation till you get it to fly right.
Possible commands are the following and you can use more than one…
I pretty much suck at figuring out the gyro rotation thing in any firmware. But I’m good at motor pins. Lol. Wish I could help more
Thanks Travis, I will keep trying!
I can’t see anything wrong with your first attempt - adding sensor_flip_180 under sensor_rotate 90_CW, and motor order 6-7-4-1 i.e. BL-A6, FL-A7, BR-B1, FR-A4. Which is how you had it in the config.h you linked to, and how NFE said to do it. Weird.
Are you 100% sure the props are spinning in the correct direction? Otherwise maybe test with standard B03 firmware just to be sure something’s not broken in this firmware? Sounds almost like something going on on the PC side too. Are you using Windows and Keil?
Ok, I’m sure it’s somewhere and I just missed it…
I have an 85mm ducted whoop with a Betafpv lite board, it seems to fly fairly well with the exception of going wonky on dropping altitude while in level mode, can’t say for Acro as I am just learning it.
It’s very unstable while dropping down and unexpectedly yaws.
Is this a PID problem or filtering?
Thanks to all for trying to help me with the upside down Beecore lite…
I went back to swapping 0-2 & 1-3 and tried every combo of SENSOR_ROTATE
The #define SENSOR_ROTATE_45_CCW is the ONLY one that the quad would at least lift off before flying straight at the wall at some bizarre axis.
Im done messing with this FC for this upside down application…and probably anything else!
I would think thats a power problem…
What spec battery are you running?
Any chance the power leads need resoldering?
New batteries, good solder, it is faster than anything else I have flown thus far, it’s agile as hell, it is only while dropping the throttle and altitude it flutters and yaws.
I am running with VERY_STRONG_FILTERING selected.
@NotFastEnuf, I was wondering - did you give up on your FEED_FORWARD code?
Lousy weather here lately - haven’t been able to fly - rats!
@chime13 - yes I abandoned feed forward. While an amazing idea in theory - it’s an extremely complex idea to pull off partially and requires some rather advanced algorithms in code. Once you get all that perfectly right - the end result feels no better than a d term calculation based on error instead of measurement … which is extremely simple and straightforward code. Plus there is also the advantage of being able to tune this “stick accelerator” and “stick transition” individually on each axis to create an entire range of possible feels as well as switch profiles in flight because it isn’t processor intense to crunch through it. So, feed forward is set aside for NFE.
@gwhoop… are you dropping straight down into your own prop wash or is this occurring during forward motion altitude drop into clean air?
The reason I ask this is in regards to the physical limitations of a whoop. There just isn’t enough motor head room to handle a drop straight into prop wash - you have to seek clean air. But if you’re in forward motion - this behavior is unexpected. Keeping as much motor head room as possible to make rapid adjustments is the KEY to amazing flight characteristics on a whoop. Vibration noise eats this up, a prop slightly rubbing a duct eats this up, a bent shaft can eat this up. The fact that you’re moving to very strong filtering concerns me that you have a physical/mechanical issue that needs addressed. Your whoop should fly FANTASTIC on weak filtering and prop wash handling is also the best here. Go back to weak filtering and then scrutinize your props, motors, and frame till it runs smoothly. Pinch a motor can and blow into the prop it to spin it up. Any vibration is a fail. Sometimes new props suck. Sometimes I’ve slightly bent a shaft on the first crash. If you make sure your ducts aren’t rubbing props, all motors spin up butter smooth and freely (no hairs wrapped up on the prop shafts or stiff motors), props are not off balance, and weak filtering so the pid controller is taking advantage of good parts - it will rip the way it’s supposed to.
Thanks for the tips, I think I started the wrong way with the filters and I am going to drop to weak filtering.
Prop wash may be most of it, dropping straight down definitely is unstable and it’s while moving slowly.
Any of the pre-configured PIDs give me a good starting point for my configuration?
You know I have no idea really. I’ve never tried to tune larger ducted. Maybe the boss 7 experimental tune with torque boost? If not that, then start with the default tune, and crank D up on roll/pitch till you find the noise limit. Throttle will not respond right. It will not drop quickly after a blip up and will want to stay up. Then you know how much D you can run cleanly (noise free). Start increasing P after that till they feel nicely in balance. Increasing filtering is a compromise when you can’t get enough clean D to settle P bounce back. But too much filtering will reduce how much P you can run without oscillating all the time. That’s the gist of the formula. It’s a balance. Less filtering means higher P is possible (P eliminates large errors), but also reduces how much D you can run cleanly. P needs D to settle it down. If you can’t get enough D clean - you have bounceback & noise issues. So you increase filtering and then maybe need to also reduce P cause it can oscillate all the time from the latency introduced in filtering.
Are the new e011’s not compatible with ST-link?
I’ve read that it’s not possible to flash the new ones. I’ve got an e011 and an ST-Link, but it doesnt connect (I see the st link blinking, but then I get an error, that it failed to connect).
Take a pic of the top of the board