Problem with Trim and Parameter tuning

#1

Hey I am a little desperate getting my drone into a stable hover state…

I tried everything to setup the build as perfect as possible:

  • Correctly determine the center of gravity following this guide Drohne_PID-Regelung (look at the end) and mount the FC there
  • Level the Drone with small weights to match the center of gravity while balancing
  • Calibrate ESCs properly
  • Set correct max and min values for RC Outputs

When getting the drone off the ground, there is still a little movement towards one direction so I try to find the perfect settings with RC trim, to adapt these values to the equilibrium torque params later, but here the problem begins:

When I try to apply trim to a channel, the changes are noticeable, but after a while the FC somehow reverts the changes by self-leveling or correcting these values during flight. Therefore I have to apply more and more trim until I am at the end of the possible range.
After landing and Re-Arming the applied trim is not working as expected. Sometimes starting is not possible without getting the drone to flip in the direction of the applied trim. This way it is impossible to find correct values for a stable hover.

I tried this with and without calibrating IMU before every flight. With parameter CAL_GYRO_ARM = true I have the feeling that after every liftoff I need to apply other trim values to stop the drone from drifting.

It seems that the FC is somehow overriding/adapting the FC signals while flying. This makes it impossible to find a good calibration or fly longer than 1 Minute. After this time you will reach max-value of the FC-Stick to correct the position drift of the drone, making it necessary to land before crashing.

I have no idea what causes this behaviour and what I can do to stop it.
Please help if somebody has an idea…

I am using the latest release of rosflight firmware, maybe it is worth to compile the newest version by myself and hope that this behavior is already fixed?

#2

Hi @rafa2602, sorry for the slow reply. It’s probably worth building the most recent firmware yourself and trying that before digging too much further into things.

Unfortunately, the most recent release is very outdated at this point. We’ve been putting off another release while we’re trying to work out some bugs with the I2C driver on the F4, but for basic multirotor flight it works very well.

Additionally, I’d highly recommend switching to and F4-based flight controller if that’s a possibility. We’re not really currently developing for the F1 anymore (the newest firmware works, just not all features). In addition, the F4 based boards have the reliability advantage of the IMU being on a dedicated SPI bus, rather than sharing an I2C bus with other sensors like the F1. Unfortunately the CC3D Revo seems to have been discontinued, but we’re still using this version here with success.

At a minimum though, I’d suggest building the latest firmware for whichever flight controller you’re using. Does that solve your this issue for you?

#3

Hey @dpkoch thanks for your answer.I will try to build the firmware from scratch.

At the moment we think that our Estimator configuration causes this issue, so we need to play a little around with the FILTER_KP and FILTER_KI parameters.

I would like to switch to an F4 based FC, but I would avoid ordering from USA due to customs and shipment costs. But I found a very similar FC that is available in Europe: http://copterjungle.de/f4-revo-stm32f405-flight-controller/

Do you think it should work with this version too?

#4

Update:

I tried playing around a little with FILTER_KP and FILTER_KI Parameters, but it didn’t had the desired effect. Maybe I need to increase the value changes for having the effect?

How is it possible, that the FC resets the RC-Trim after Re-Arming? I finally managed to do a rc-trim-calibration, but therefore I had to apply all trims without re-arming.

Is a barometer recommended, or in other words: how much does the firmware benefits from it for vertical stabilisation?

Regarding the F4 I mentioned above, it seems that it is the same board as this one: FLIP32 F4. Has someone already been running the firmware on it?

#5

Hi @rafa2602, sorry for the slow reply. The flight controller you linked to seems like it should work just fine. I don’t know that we’ve tried running the firmware on the Flip32 F4 specifically, but any board that uses the Revo schematic (which it seems like the one you linked to does) should work.

The behavior you’re describing with the trims is strange. Have you flashed the latest firmware to your F1 board yet? If not, that’s the first thing I would try and then check to see if you’re having the same issue.

My best guess is that the gyros might be drifting quickly (as in a quickly-changing bias). This would explain why the attitude seems to drift during flight (requiring more and more RC trim to compensate), but then resetting when you arm (causing the vehicle to try to achieve the attitude indicated by the large trim values) as that’s when the gyros are calibrated again.

To help determine if this is the case, I would record a rosbag of the raw IMU data and the attitude estimates while the drone is sitting level and stationary. This should let us quickly see whether the gyros are drifting, or whether they’re okay but the filter is diverging for some reason. Also, if you have another board it could be useful to try with that one to see if the issue is limited to one board with perhaps a bad IMU (we’ve seen cheap boards with knockoff IMUs before that can cause issues).

To summarize, my recommended course of action would be:

  1. Flash the latest firmware (built from source) on your board, even if it’s still the F1 board (or put it on the F4 board if you’ve already gotten one). See if the issue persists.
  2. Record a rosbag of the raw IMU data and the attitude estimate while the drone is sitting level and stationary, so we can see if the gyros are drifting or the estimator is converging
  3. Try another flight controller board, if you have one
#6

Hey @dpkoch I builded the firmware from source with the latest commit from the master-branch [51c8049], and flashed it on the F1 Naze32. Everything seems to be ok, except for arming. Is it possible that the issue is related with https://github.com/rosflight/firmware/issues/370? Maybe the expected values (1000-2000) are not reached at the moment (0-1000) by moving the switch? Do you know when this change was introduced, so I could go back on master-branch to build a working firmware with the specific commit?

#7

What issue are you having with arming? Does rosflight_io output any useful message, like “failed to arm because of error XXX” (that’s not the exact wording)? Have you calibrated the IMU and set the mixer? Those are the most common reasons the firmware won’t arm after re-flashing. Note that flashing a new version of the firmware resets all parameters so you’ll have to set them again.

That issue only affects how the RC values are reported, not how they’re used internally. So it shouldn’t be causing any problems beyond confusing people.

#8

Thanks for your quick answer. The issue is: it just doesn’t arm, without any error or useful message…
Before flashing I wrote all params to disk and after flashing I loaded them from file. As I noticed some differences (parameter-definitions changed) comparing the files exported directly after flashing with the backup, I did another try setting only the necessary parameters by hand after flashing. I set mixer and arming-channel correctly, and I calibrated the IMU. This is a quite strange behavior…