Thread Tools
Sep 26, 2020, 11:10 AM
Certified Nerd
Thread OP
Quote:
Originally Posted by MGeo
Hi All,

Posting in case this is of interest here. I've had some luck porting the Arduino based code over to STM32F411CE Blackpill (https://stm32-base.org/boards/STM32F...Pill-V2.0.html) and an MPU9250 breakout board. I'm using this Arduino core https://github.com/stm32duino/Arduino_Core_STM32. SPI is used to talk to the MPU9250, fast SCLK speed is set to 6MHz.

The advantage of this core is the long list of STM32 parts it covers (https://github.com/stm32duino/Arduin...aster/variants) including the F411CE Blackpill, STMF405RG (found on the many F4 flight controller boards) and more. The disadvantage is the sometimes lower maturity level of the core and libraries relative to Teensy.

The main advantages to me are the migration path to existing low cost flight controller hardware, and the availability of hardware debugging (Teensy does not support hardware debugging that I know of, just embedded print statements). I'm comfortable with soldering and breadboards but an available flight controller would make things easier. If I retarget to STM32F405RG the code "should" run on a Sparky2 board. I have a few of these, you can still find them here for $30 (https://www.motionrc.com/products/ta...ght-controller). I would like to get MPU6000 running as this would open up a host of current low cost FC options, Matex targets, etc.

Nick, I realize this may be a distraction from the Teensy based project you've started here so will start a new thread if you would prefer. I will be posting the code up on GitHub as soon as I get a chance to clean things up a bit. I started with the code here, not too much modification was needed to move it over to this core but as always the devil is in the details

Best Regards,
George
Awesome! Feel free to either post your updates here or start a new thread. I'll be following along . Interested to see if you can keep the code above 2kHz on the slower board... That's why I opted for Teensy4 with the M7 processors
Sign up now
to remove ads between posts
Sep 26, 2020, 11:12 AM
Registered User
Actually Madgwick will have the same problems in accelerated flight. It’s missing an accel cutoff that gracefully removes the accel fdbk when the absolute value of measured g is above or below 1g by a certain threshold. I have some code somewhere to do that.......
Sep 26, 2020, 02:40 PM
Registered User
MGeo's Avatar
Quote:
Originally Posted by rcjetflyer2
Awesome! Feel free to either post your updates here or start a new thread. I'll be following along . Interested to see if you can keep the code above 2kHz on the slower board... That's why I opted for Teensy4 with the M7 processors
Ah good question, I was wondering that too. I put a test pin in the code that drives the test pin high at the top of the main loop, and then toggles it off at the bottom of the loop right before the spin wait. I then added the test pin to the logic analyzer trace.

You can see the main loop calculations take 0.314ms out of 0.500ms for 2000 Hz loop so ~35% margin. And this on a 96MHz F411 processor. The common F405RG can run at 168MHz so a good bit faster. Also I have the SPI running at 6MHz due to my open breadboard wiring. An MPU9250 read is taking about 66 uSec. I should be able to push that up to at least 12MHz and save some time there. Finally this code is reading 9 registers (acc/gyro/mag) instead of 6 (acc/gyro).

So I'm feeling pretty good about 2KHz even now with a decent amount of room for improvement. I think maybe the M7 Teensy was needed because the 1MHz MPU6050 I2C transfers were taking up a substantial portion of the loop time?

George
Last edited by MGeo; Sep 26, 2020 at 02:49 PM.
Sep 26, 2020, 02:44 PM
Certified Nerd
Thread OP
Quote:
Originally Posted by MGeo

So I'm feeling pretty good about 2KHz even now with a decent amount of room for improvement. I think maybe the M7 was needed because the 1MHz I2C transfers were taking up a substantial portion of the loop time?

George
Good to see you're still getting good loop rate. I started on arduino nano running I2c on the 6050, then moved over to the teensy for more raw horsepower. So yes--Teensy let me get away with some of my sloppy code and I2C IMU connection. You can probably tell by now this is my first arduino project
Sep 26, 2020, 02:53 PM
Registered User
MGeo's Avatar
Quote:
Originally Posted by rcjetflyer2
Good to see you're still getting good loop rate. I started on arduino nano running I2c on the 6050, then moved over to the teensy for more raw horsepower. So yes--Teensy let me get away with some of my sloppy code and I2C IMU connection. You can probably tell by now this is my first arduino project
No worries, you have a great project here. Your efforts to document and share out the work are much appreciated.
Sep 28, 2020, 07:43 PM
Certified Nerd
Thread OP
I've got the mpu9250 hooked up on SPI and working for 6DOF madgwick but am still troubleshooting 9dof implementation. So at the moment, you'll be able to use either the 6050 or 9250 but will get the same attitude estimate accuracy until the magnetometer is used. Also, I borrowed a buddy's taranis and am now testing SBUS and everything looks good. I'll start working on updating the documentation for the upcoming changes/features. Hopefully the solution for the 9dof madgwick shows itself in a timely manner and I can roll this next code version out soon...
Sep 28, 2020, 11:54 PM
Certified Nerd
Thread OP
SBUS is a success, and I think I finally figured out the magnetometer/9dof filter issues. It will require a 1-time calibration where you will follow the typical rotating the IMU procedure, then you can set and forget the bias and scale factors if you're flying at the same field.

Tomorrow I will finish packing up the code and make the necessary updates to the documentation
Sep 29, 2020, 04:05 PM
Registered User
MGeo's Avatar
Quote:
Originally Posted by rcjetflyer2
SBUS is a success, and I think I finally figured out the magnetometer/9dof filter issues. It will require a 1-time calibration where you will follow the typical rotating the IMU procedure, then you can set and forget the bias and scale factors if you're flying at the same field.

Tomorrow I will finish packing up the code and make the necessary updates to the documentation
Great news, looking forward to it!
Oct 01, 2020, 01:36 AM
Certified Nerd
Thread OP

Beta 1.2 Released!


Hey Everyone,

I've been working hard on getting 1.2 put together and documented. A few setbacks over the past week or so, but now we're here. Some updates:
  • SBUS receiver support
  • MPU9250 support
  • New IMU/radio selection: simple defines in beginning of code
  • IMU gyro and accelerometer scale selection: up to +/-2000 deg/sec and +/-16 Gs
  • Added switchRollYaw() function (see documentation for details)
  • Added printServoCommands() function
  • Switch between controller types with a logical statement in the main loop
  • Minor bug fixes & tidying up

I highly recommend you check out the updated documentation (in the first post of this thread or on github). For expedited setup, check out the "General Instructions for First-Time Setup" tutorial at the end of the document to get up and running as fast as possible.

The MPU9250 integration was difficult to say the least, but I think I finally got it working. The MPU9250 requires some special attention when it comes to soldering up with the Teensy as well as adjusting some filtering parameters for it. You'll also have to do some calibration, but that is as simple as uncommenting a function at the end of the void setup() and performing the calibration by rotating the IMU for a minute or so. Check out the "MPU9250 Integration" tutorial for more information on everything to do with the MPU9250. I will still HIGHLY recommend sticking to the MPU6050, as that is the IMU that this code was originally built around.

There were some small bugs that were fixed. You can now seamlessly switch between controller types (angle or rate) in the main loop with a logical statement should you code that in. Also fixed a dumb error/bug with processing the IMU data.

Speaking of the IMU data, I need to thank jihlein for his amazing help overhauling the IMU data gathering (enabling MPU9250 use too). He is responsible for the new define section at the beginning of the code that makes selecting IMU, IMU data scales, and receiver type extremely easy to do. So big thanks to him One thing you will now need to do is copy the required libraries (included in the dRehmFlight download) and paste them in your Arduino libraries folder. More details in the Software Setup section of the documentation

Looking forward to seeing some of you get flying
Oct 01, 2020, 02:08 AM
Registered User
RCvertt's Avatar
Quote:
Originally Posted by rcjetflyer2
SBUS is a success, and I think I finally figured out the magnetometer/9dof filter issues. It will require a 1-time calibration where you will follow the typical rotating the IMU procedure, then you can set and forget the bias and scale factors if you're flying at the same field...
Congrats on getting SBUS working.

For the IMU calibration. Do you mean I can rotate my aircraft around on day one, come back day two and not have to rotate my aircraft around as long as I am at the same field. Even if I have powered down? If so, that sounds like an acceptable compromise to me.
Oct 01, 2020, 08:40 AM
Certified Nerd
Thread OP
Quote:
Originally Posted by RCvertt
For the IMU calibration. Do you mean I can rotate my aircraft around on day one, come back day two and not have to rotate my aircraft around as long as I am at the same field. Even if I have powered down? If so, that sounds like an acceptable compromise to me.
Yes--following the calibration procedure, the serial monitor will print out 6 scale and offset values, which you can then paste into the code in the user-specified variable section. After that, comment of the calibrateMagnetometer() function in the void setup() and you're good to go.

I would still verify good attitude estimate every time you go to the field with printRollPitchYaw(), however. That way you'll know if the mag calibration has gone bad before attempting flight. Magnetometers are finicky...
Oct 01, 2020, 10:54 PM
Registered User
RCvertt's Avatar
Nice! Just like how Joop calibrates the accel. Set it and forget it like you said.
Last edited by RCvertt; Oct 02, 2020 at 03:15 AM.
Oct 03, 2020, 07:23 AM
Registered User
MGeo's Avatar
Posting my STM32 port of V1.2 code here: https://github.com/geosmall/dRehmFli...STM32_BETA_1.2

You can see I renamed the MPU9250 and SBUS libraries into src subfolder under the sketch. I did this because I started making changes specific to STM32 and did not want to create confusion and Arduino library version hell. This means everything is self contained in the sketch, no need to add libs to Arduino Library folder.

SPI looks to be working. I see the loop code is taking a bit longer but still decent margin at 2KHz loop on F411CE Blackpill setup seen in my earlier post. Next up is testing of inputs and outputs.

George
Oct 03, 2020, 03:55 PM
Registered User
MGeo's Avatar
I hooked up my logic analyzer to Teensy 4 test setup (attached). It looks like the loop samples the SPI in main loop at 1MHz. Plenty good enough for 2KHz loop it looks like, but using a faster SPI would allow for more room for growth.
Oct 03, 2020, 04:06 PM
Registered User
MGeo's Avatar
I added the following line ("_useSPIHS = true;") to the getMotion6/9 routines to use the SPI high speed. The library author used this flag to modify the SPI clock speed in the readRegisters() function. The loop time drops to 0.153 mSec. The Cortex M7 at 600MHz does indeed have some horsepower.

Code:
// jihlein additions start

void MPU9250::getMotion6(int16_t* ax, int16_t* ay, int16_t* az, int16_t* gx, int16_t* gy, int16_t* gz) {
    uint8_t buffer[14];
    _useSPIHS = true; // use the high speed SPI for data readout 
    readRegisters(ACCEL_OUT, 14, buffer);
    *ax = (((int16_t)buffer[0]) << 8) | buffer[1];
    *ay = (((int16_t)buffer[2]) << 8) | buffer[3];
    *az = (((int16_t)buffer[4]) << 8) | buffer[5];
    *gx = (((int16_t)buffer[8]) << 8) | buffer[9];
    *gy = (((int16_t)buffer[10]) << 8) | buffer[11];
    *gz = (((int16_t)buffer[12]) << 8) | buffer[13];
}

void MPU9250::getMotion9(int16_t* ax, int16_t* ay, int16_t* az, int16_t* gx, int16_t* gy, int16_t* gz, int16_t* mx, int16_t* my, int16_t* mz) {
    uint8_t buffer[20];
    _useSPIHS = true; // use the high speed SPI for data readout
    readRegisters(ACCEL_OUT, 20, buffer);
    *ax = (((int16_t)buffer[0]) << 8) | buffer[1];
    *ay = (((int16_t)buffer[2]) << 8) | buffer[3];
    *az = (((int16_t)buffer[4]) << 8) | buffer[5];
    *gx = (((int16_t)buffer[8]) << 8) | buffer[9];
    *gy = (((int16_t)buffer[10]) << 8) | buffer[11];
    *gz = (((int16_t)buffer[12]) << 8) | buffer[13];
    *mx = (((int16_t)buffer[15]) << 8) | buffer[14];
    *my = (((int16_t)buffer[17]) << 8) | buffer[16];
    *mz = (((int16_t)buffer[19]) << 8) | buffer[18];
}

// jihlein additions end


Quick Reply
Message:

Thread Tools

Similar Threads
Category Thread Thread Starter Forum Replies Last Post
New Product Radiolink-Byme-A-D Flight Stabiliser Flight Controller Gyroscope Self-stabilization Merch Banggood.com 0 Aug 13, 2019 09:45 PM
Discussion 3 Axis-A AUX Control System Gyro Flight Controller Stabilizer For FPV Flying Wing EDF scousethief Banggood.com 0 Aug 05, 2018 06:58 AM
Discussion Is there a fixed wing flight stabilizer that can control yaw by thrust vectoring? jamieFL FPV Equipment 23 Apr 01, 2018 11:46 PM
Discussion OpenAero-VTOL Flight Controller Introduction Ran D. St. Clair 3D Foamies 0 Oct 05, 2015 03:34 PM