Questions regarding trimming

Hello,

This is Prashant and I am running rosflight on the Flip32 board controlling a Y6. I have the following questions:

1) Since the battery is the heaviest component in my vehicle, my trims are a function of battery placement. I had initially set the trims the first time after building it (the trims were huge) and it worked fine. What I am concerned about is, if I trim again I think the firmware rewrite over the old trims instead of adding to the old ones. This is a problem because my first trim values were huge and my second iteration was not big and when I set it again it rewrote over the old values and made flying really difficult. Could you please clarify on how this works?

2) I am trying to feed in attitude commands to the controller using the /command topic. I think that, when the mixer converters it to motor commands, it add the trim values too. When I give the commands, I loose control authority on axes which have some trim on them. Once I set the trim back to zero, I gain full control. Something tells me this should not work this way and I have a feeling that the trims should not be added to the computer generated commands.

Prashant

Comments

  • 10 Comments sorted by Votes Date Added
  • Hi Prashant,

    1) Ah, yeah I can see how that would be a problem. You're correct that the it's overwriting the saved trim values instead of adding to them. While annoying in your case, I think that's actually the most generally useful behavior so we probably won't change that. What you'll want to do is zero out the trim parameters (X_EQ_TORQUE, Y_EQ_TORQUE, and Z_EQ_TORQUE) using rosservice call /param_set X_EQ_TORQUE 0.0, then fly and set your trims again, which will now be the full value of the trims. We should probably update the documentation to reflect this.

    2) You're correct that the trim values are being added to the computer-generated commands. These trim values are added as a feed-forward torque after the attitude controller runs, regardless of whether the attitude setpoint is from a human or a computer. This should be transparent to the user; if the pilot or the computer requests a certain roll angle then the vehicle should go to that roll angle; the trim values are applied internally to help that happen. So I'm not sure what's causing your problem. Just to clarify, do you only have an issue with computer control but not manual control, even with the same trim values?

  • 1) As you know the Y6 is an very difficult platform to trim and has an inherit yawing issue. From what you are saying, when I have a "big" initial trim and I want to add to this, I will have to redo the trim again? As opposed to just adding some additional torque? To me, adding makes more sense because there is already an option to setting all the torques to zero so technical there are two ways of doing the same thing.

    2) This issue occurs when I give computer input (Giving velocity commands through an Xbox controller). When you give computer generated command calculated through a PID loop, you have bounds on the attitudes. Adding the trims makes you lose control authority in the axis which has the trim. This is generally not a good thing because to over come this I have to increase these bounds which can be dangerous at times.

  • 1) That's a good point, and I think I agree with you that we should change that. I've created an issue at https://github.com/rosflight/firmware/issues/288. But for the way it's implemented right now, yes, you'll need to redo the trim until we get that changed.

    2) I still don't quite understand the issue you're having here. In the firmware we're not applying any bounds to the angle you're allowed to command in a computer setpoint. We're only doing that for RC control, and even then it's more of just a scaling factor on the stick command. The trim torques are applied after the attitude controller runs, the same way for RC and computer control, and should only help to achieve the attitude angles that have been commanded. Which bounds are you increasing for things to work?

  • One possibility is that if the attitude commands you're sending over are too aggressive, you could be saturating motor commands which makes control more or less impossible, and usually affects yaw first. Which axis are you having difficulty controlling? Would it be practical for you to get plots of the attitude commands you're sending as well as the motor commands (the output_raw topic) while you're having this issue?

  • Let me clarify, right now there is a setup where I can give velocity commands using a xbox controller. The "computer" converts these velocity commands into attitude commands using a PID loop (the "computer" also estimates body frame velocities). The problem I am having is, when I fly the vehicle using this setup while having some trim (for example in the pitch axes) the PID loop does not have complete control over the pitch axes.

    This is exact what happens:
    Setup: A Y6 taking velocity commands from an xbox controller. There is some trim on the RC transmitter, the RC transmitter is also the backup in case anything goes wrong.

    Event: When give it zero velocity command, in an ideal world it should hover in the sample place. But in other vehicles (not this one!) and control strategies it would drift away really slowly. But what happens here is, the drifting happens a lot faster and when I try to give it velocity commands to bring the vehicle back, it does not respond to the axis that has trim. I did try and change the PID gains, the saturation limits of the control commands given to the flight controller (there is saturation here for relatively smaller angles eg. 10 deg vs 17 deg). I also checked the output_raw topic and there was no saturation there.
    When I move a battery around a bit and bring the trim values close to zero, I have complete control of the vehicle and the vehicle also doesn't drift as fast. So this makes me thing that when the fight controller is in COMMANDED mode, it shouldn't add the trim values because in my case at least I feel the PID loop will compensate for it.

  • Are the trims still applied on the transmitter itself, or have you called the calibrate_rc_trims service and then set the transmitter trims to zero? The second way is how the firmware is designed to work; if you still have non-zero trim values on the transmitter itself that could explain what's happening.

    Here's what would happen if you had non-zero trims on the transmitter, instead of storing them in the firmware: The vehicle would fly great under RC control because it's getting trimmed attitude commands. But then the computer would send attitude commands that do not have this trim, and then you'd get some steady state error in attitude that would cause it to drift a lot. This could be countered by adding some integrator gain, but it would take a while to converge.

    On the other hand, if you store the trim values in the firmware and then reset the RC transmitter trims to zero, then both the RC transmitter and computer send nominal, or untrimmed, attitude commands, and the firmware uses the saved trim values as a feedforward term to help combat the steady-state error more quickly than just an integrator could.

    So could this be what's happening? Do you have non-zero trims on the transmitter itself?

  • 1) I do have some trims on the transmitter itself and a nominal trim on the firmware side. I haven't added the trims from the transmitter to the firmware because it would erase my nominal trims.
    2) Yes, I agree with you that the integral control would negate steady state error apart from the drifting issues I also have a problem of losing control authority on the axis that has trims on them. The drifting portion is as big as a problem as losing control authority and I feel that the firmware taken the trims from the RC AND the nominal values when it is controlling with attitude set points.

  • 1) Okay, so the firmware is not designed to work with this setup, and so I think the issues you're seeing aren't surprising. You'll need to transfer those trims to the firmware in order for computer control to perform well. If you don't want to lose the nominal trims you have, just use rosservice call /param_save_to_file <filename> to save them to a yaml file, from which you can always restore them. (If you want to restore only those trim parameters, just copy the appropriate lines from the full yaml file to a separate yaml file and load it using rosservice call /param_load_from_file <filename>.)

    2) The firmware has no way of knowing which part of the RC signal is from trim on the transmitter versus from you moving the sticks. So when you have a trim on the transmitter, you're effectively sending an attitude command with an offset. This works fine for RC control, but then the computer doesn't know about that offset so the attitude commands it sends will appear to not perform well. I'm not exactly sure what you meant by your last sentence, but I suspect that saving the trims to the firmware will fix your problem. I'm going to need you to try that out before we can figure out if there's some other issue going on.

  • After having a discussion with @dpkoch , I learnt that when you are controlling a vehicle through a computer and have a trim on your RC that is greater than 10% on any axis, the computer does not have control on that axis. So basically, its a good idea to set all RC trims to zero (by transfering them to the firmware).

    @dpkoch please correct me if I'm wrong

  • Yep, that's correct. The trim value looks to the autopilot like the safety pilot is trying to override that axis, so for that axis it follows the RC instead of the computer

Sign In or Register to comment.