Yes, the range for RUDD_DT_GAIN is 0-100%
Thanks! I set mine to 0. Hopefully Iāll get a chance to fly it this weekend and get my forward flight tuning done, so I can start experimenting with the limits of the transition
@tridge @mrjadkowski
Regarding a different AHRS_TRIM values for Q modes:
Perhaps a new parameter which specifies optimal cruise pitch for FW. That would be the pitch required to hold altitude at cruise throttle under standard conditions, and in stabilized modes that would be the attitude with the sticks centered. I assume that AHRS_TRIM_X/Y should be set so that the artificial horizon displays correctly, not to reflect cruise attitude.
@kd0aij I think Iād prefer to leave the existing fixed wing trims, but be able to have different trims in Q modes. So perhaps Q_TRIM_X and Q_TRIM_Y ? You would trim those when you are in a Q mode, using the same trim mavlink MAV_CMD_PREFLIGHT_CALIBRATION command.
For a tailsitter the Q_TRIM_* values would apply to the AHRS_View used for the tailsitter orientation.
The Q_TRIM values sound good to me. But Iām still not clear on the purpose of the AHRS_TRIM params: do they specify cruise attitude, or pitch/roll level with the horizon?
They definitely specify your pitch/roll level with the horizon. The cruise attitude question is a little more complicated. My understanding is that in FBWA, with no pitch or roll inputs and a cruise throttle setting, the autopilot is attempting to keep the pitch and roll atttidue of the airplane at zero and zero according to whatever is set with the AHRS_TRIM parameters. Stabilize and hover (altitude hold mode in copter) basically work the same way. However, in my experimentation, Iāve found that the AHRS_TRIM parameters have much less effect in AUTO. Without an airspeed sensor, the biggest single influence on cruise speed that Iāve found is the physical pitch trim (i.e. the amount of up elevator and/or stabilizer incidence) when your pitch servo is at its trim value. I was able to change the cruise speed of one of my airplanes by +5 m/s (thatās almost 50% of the max endurance speed) by simply decreasing the trim angle of the full-flying stabilator by a couple of degrees, with no changes to the autopilot Iāve also had an autopilot fall off its mount during flight so the HUD was showing ~20 degrees of bank and ~15 degrees of pitch in level flight, and it continued to fly fine in AUTO mode.
The reason why I asked about different AHRS_TRIM values for vertical and forward flight is that I found the AHRS_TRIM values I set for what looked like an appropriate amount of nose-up pitch for forward flight causes my tailsitter to constantly drift backwards in a hover. With two separate trim values, I can set up my Q trims for a stable hover in no wind, and my forward flight trims for the most efficient cruise attitude in forward flight.
OK, so youāre using AHRS_TRIM to set cruise attitude at center stick in FBWA, not to make the artificial horizon read correctly; āAHRS_TRIM values I set for what looked like an appropriate amount of nose-up pitch for forward flightā
So your logs will show zero pitch at cruise, even though thatās probably several degrees above the horizon.
Thatās my understanding of it, based on my own experiences.
@tilt can you tell us a bit more about the control mixing scheme youāre using?
For example, in your latest video:
in hover, are you using elevons at all for roll/pitch/yaw? Or is it flying just as a bicopter, using the vectored control of the motors and letting the elevons sit still? Or are you mixing both at the same time in some proportion?
Iād like to start adding vectored support to ArduPilot tailsitter code, and starting with your successful mixing scheme seems like a good idea.
Cheers, Tridge
Hi, Tridge and fellow avation pioneers, all funtioning full time, but not sure tilt is needed in ff ?
thrust tilt, may be causing adverse yaw ?
up elevator= up motor tilt,same with roll, up aleron = up tilt etc.
seems to be very dificult to stall with tilt + power,
might be on to something, want to do more experimenting
might be the safest air plane design so far,or just over powered ?
btw, pixhawk won;t load with latest s/w, back to the pixracer.
about to test fly when wind calms
note the yaw with the short cuppled wing on the latest video
have to activly use diff. thrust to keep it stright.
yes, I expect it isnāt needed in forward flight
ok, so in hover itās just using the servo tilt?
yes, Iād expect some yaw coupling. We could have a feed-forward term to counter that, though I expect with the right tuning the yaw controller will cope.
can you tell me what error you get? How are you loading the firmware? What exact board are you using?
#2 full time tilt and control serfaces in hover and ff
#3 software not compadable with board, mission planner, costom f/w, downloaded from latest
it loaded into pixracer no problem
don;t know why printed so big? ^ china 2.4.8 board, banggood?
@tilt What is the maximum angular deflection of the elevons, and tilt of the motors?
And do you find that gains are very dependent on CG in hover?
Hi, with the tail sitter about 20-25 deg on both, but I like extra control, the cg can be almost anywhere, does not seem very critical,
but I have been using standard flying wing cg around 25%
that means it is loading the wrong firmware varient. The firmware you want is this one:
http://firmware.ap.ardupilot.org/Plane/latest/PX4/ArduPlane-v2.px4
download that, and load it with āload custom firmwareā in MissionPlanner.
MissionPlanner should have detected the right firmware to use itself, but maybe that failed for some reason.
There are 4 different varients of the STM32 fimrware:
- FMUv1: ancient px4-v1 boards
- FMUv2: majority of Pixhawk-like boards
- FMUv3: newer pixhawk-like boards with 2MByte of flash available
- FMUv4: pixracer boards
the error message means you are loading the wrong one
do you have separate PIDs for the control surfaces and servos? Or a fixed ratio between them and one set of PIDs? Or are you controlling things more manually in the transmitter?
Thanks ,one output feeds both tilt and serfaces,just cross feed them, l motor/ r aleron, same pids
1 Like
ok, so Iāll do the same, but add a mixing gain parameter for the ratio to each.
Iāll lock the motors straight forward for forward flight.
For landing, I think always making the motors point straight up to the sky would be best
Hi, it loaded fine but no be bop tone at the end to tell it will connect
yes but you might want to try both options with a mode?