VTOL: Back transition Ramp Up problem.

[tubeme]

Hi guys,

I think we found a bug in the Position / Mission modes for vtol. Trying to fix the #8655 we made the VT_B_TRANS_DUR from 3 sec to 5 sec. And with the VT_B_TRANS_RAMP set to 3 sec. the ramp up of the quad motors to the "commanded thrust" happens in the middle of the transition and the throttle stays at that level up to the end of the transition, then it pasees the throttle to the MC.

In our case In Position mode the hover throttle is at 0.6 for the MC. So it is logical that the ramp up of the quad in the back transition go from 0 to hover throttle in order to hold the MC at current altitude (the idea behind Position mode) and continue like this up to the end of transition then pass the throttle to the MC to continue in Position mode until it stops.

The problem is that for the back transition ramp up commanded throttle PX4 uses VT_TRANS_THR which is the throttle for the front transition pusher motor.

You can see it clearly in:

Mission

LOG: https://logs.px4.io/plot_app?log=e6381c08-4b42-41f2-a01b-bd9f7f0bbb58

Position

LOG: https://logs.px4.io/plot_app?log=66fa60a2-e7b4-487e-b916-3c45f024daf3

We could not see this up to now because we had a 3 sec back transition with 3 sec ramp up and with pretty low VT_TRANS_THR = 0.7 . Now because we fight the fron transition ramp up problem #8664 we made the VT_TRANS_THR = 0.9 and found out that during the back transition in Mission and Position modes the quad trhottle during the transition is so high that the VTOL just gains some 10-15 meters og height during the transition. It holds horizontal level but climbs drastically during the transition and then drops suddenly to hover throttle once in MC.

In Mission and Position modes neither the front transition ramp up neither the back transition ramp up are such to allow a smooth transition. at given altitude.

[tubeme]

@LorenzMeier @dagar @sanderux

I wonder if we are the only one with this problem? Are we missing some parameters?

[dagar]

You're saying the VT_TRANS_THR parameter (transition to FW pusher throttle) is being applied during back transition?

[tubeme]

@dagar I have no other explanation why the throttle in the ramp up goes to 0.9?? Any other explanation? It just happened that we changed VT_TRANS_THR from 0.7 to 0.9 when it became obvious. I did not find any other parameter that could cause this ramp up. Also the VTOL is flying perfectly well in MC Position and FW Position. Also we have a zillion of flights in Stabilized mode and the transition is smooth as a butter. This problem occur only the Mission and Position modes. For the last two months we concentrated our flying in the AUTO modes exclusively to properly tune the position controllers. I can give you more logs with the same pattern of ramp up it is visible in every transition we make ie 100% reproducible.

[tubeme]

Here is a log with the VT_TRANS_THR = 0.7 back transition time 3 sec and 3 sec ramp up.

Log: https://logs.px4.io/plot_app?log=a11fdda4-1d23-48c2-8596-f5c5a16e23ba

[bresch]

Hi Vasil, from the first log I think that the throttle goes up to 90% because the drone is loosing height during the back transition: It's thus just the altitude controller doing its job to reach the altitude setpoint. (90% throttle is the maximum allowed value in order to always keep 10% for attitude control)

Btw, you might have some issues with you pitot tube...

[bresch]

@tubeme Yes? No?

[sanderux]

Did you enable reverse pusher?

[tubeme]

Sorry guys I was away for a wile. @bresch I could agree with this, but in reality the quad just shoots up in the air during the back transition.

See my second log. There we changed the VT_TRANS_THR = 0.7 and see what happens with the ramp up. It goes to 0.7 and not 0.9.

Log: https://logs.px4.io/plot_app?log=a11fdda4-1d23-48c2-8596-f5c5a16e23ba

[tubeme]

@sanderux No we did not enable the reverse pusher.

[tubeme]

@bresch From the first log where the back transition is in Position mode.

Indeed the barometric reading is kind of laggy but at the same time the GPS altitude is adequate. Look at how long and what amplitude has the ramp up.

Despite we can see this:

The acc and gyros are sensing this rise in altitude.

Log: https://logs.px4.io/plot_app?log=e6381c08-4b42-41f2-a01b-bd9f7f0bbb58

I don't understand what is going on really... May be some parameter somewhere...

[bresch]

@tubeme Oh, I see, as you said and as the GPS shows, the drone is climbing. However, the baro measures loss of altitude and pulls the estimated height with it. The cause of this climbing problem is then a baro issue. It means that during back-transition, your baro might be exposed to sudden airflow. Best fix is to identify and physically fix the source of this airflow, 2nd option is to change the baro noise covariance in the EKF (however, this will increase the sensitivity to GPS glitches and accelerometer noise).

[tubeme]

@bresch We will see and try to identify why is that flow... Althoug it is mounted as it is in hte belly of the plane. But this does not mean that the issue of the ramp up related to VT_TRANS_THR is not a problem. There should be another parameter probably for the back transition ramp up level...

[bresch]

@tubeme I'm not convinced there is any link between ramp-up and VT_TRANS_THR. In every back-transition when you have the param set to 0.9, the altitude error is quite large (-> the altitude controller increases throttle up to saturation) and in the log where it is set to 0.7, the altitude error is smaller (-> the throttle goes a bit above 0.7, it doesn't look to be saturated at that value). Furthermore, I checked where this parameter is used in the code and it never affects anything else than the pusher motor... The reason why it looks smooth up to 0.9 is that the final value is not hardly set to the 'hover throttle' parameter. The ramp is just an linearly increasing weight that scales the output of the MC controller. The reset value for the MC controller is the hover throttle, but this changes as soon as there is an error between the altitude setpoint and the estimated altitude.

[sanderux]

There should be no link in back transition and VT_TRANS_THR. What i think is happening here is that the quad motor thrust somehow effects the pressure in the fuse whereby the vehicle thinks it's below requested altitude and starts commanding max thrust.

[sanderux]

ps: 0.9 is from MPC_THR_MAX @tubeme can you send a picture of your vtol?

[RomanBapst]

@tubeme @sanderux I agree with @bresch that the problem is due to the effect of the transition on the barometer. I've seen this a lot in the past, some vehicles would not transition because they were climbing during the front transition because the baro said it was loosing altitude. Thus the vehicle never reaches the transition airspeed... I've seen setups where this was hardly a problem (although I think some of them had custom hardware with proper static ports installed). I think the next autopilots should have the option to install static ports, e.g. the board could come with a nipple so that you can attach a tube and put the static port where ever you want it.

@kd0aij Used to to some interesting tests https://gitter.im/PX4/Hardware/archives/2016/03/09

[dagar]

Isn't it coupled though? In forward transition that means changing the ramp up. In back transition it can be even worse. If the MC motors come on too quickly the barometric pressure issues are worse and feed back into the altitude controller commanding even more thrust.

In both cases I suspect we'd get better results by letting the appropriate controllers handle each throttle and stop forcing things.

[sanderux]

@RomanBapst he is flying airspeedsensorless @tubeme you are flying a deltaquad type system. A good staring point is: VT_B_TRANS_DUR: 8.0 VT_F_TRANS_DUR: 1 VT_TRANS_MIN_TM: 12 VT_TRANS_THR: 100%

the maximum thrust you see in back transition is because the deltaquad returns to level from the quad perspective while doing the backtransition. This will likely cause altitude loss because your fixed wing is then pointing down. Try tuning TRIM_PITCH so your elevons are slightly up in neutral state to combat this behavior. (or mechanically offset them). Try with a value of 0.05 and see what happens on the bench in FW mode. start tuning from there.

[RomanBapst]

@sanderux I'm referring to a static port for the baro which of course could also be used for the airspeed sensor.

[sanderux]

@tubeme your setup is identical to ours and we do not have such issues. I would therefor conclude it is a matter of tuning. Closing for now. Let me know if you keep having problems.

[tubeme]

@sanderux @RomanBapst @dagar

So we made a lot of flights since this problem occured. And I think we have a pattern. SO

The baro sensor is kind of laggy. If we make the transition at level flight, the normal way, there is no problems what so ever.

But if the pane is at height and we pitch down to lower the pane height without a throttle ie with a gliding and then during this descend we make the transition, the baro is always laggy and iPX4 always does this max throttle during the back transition. So in this very moment the GPS altitude is adequate, the acceleromater data is adequate, but the baro sensor continues to lower its reading for some 2,3,4 seconds so the PX4 kicks on the throttle. We try to give more weight on tha accelerometer data in the fusion but then this is not very good for the regular flying.

We tried this on 4 different boards and it is always the same.

BTW I cannot understand when we are in airpeedless mode where the TECS get their speed information?? We did not set the ground speed to be taken instead of the airspeed.

[dagar]

Does transition need to function during a descent? Would we lose anything if we enforced stabilized altitude before beginning the transition procedure? The way the current code is designed already effectively assumes normal level flight in good conditions.

[tubeme]

Yes transition need to be fluent in all conditions. Because the novice pilots are expected to do a lot of irrational things. If there is a way to get in to account the GPS altitude as well for the fusion could be good idea. And BTW the plane is leveled during our transition innitiation. It is just that this happens after long descend . After long descent the baro is lagging behind. I spoke with a friend in the airplane industry and he told me Baros are always made with this lag otherwise the baro reading will be much frantic all the time.

[sanderux]

Did you try the params i suggested?

[tubeme]

@sanderux Yes we tried it. But we have concerns in several points during the transition some are:

1. We want to make the transition as short as possible (for strong weather that is the way). We know it works perfect because we use a KK2.0 setup with no FW controller bench mark setup. So this in reality is manual setup airplane and a attitude stabilized quad. With it we make a perfect transition to full speed in 5 seconds, and during the whole transition the KK2.0 is at 50% throttle (the hover throttle) it makes the attitude corrections and at the end of transition just go to 0% throttle. This is pre-programmed in a Taranis. So it is a flip of a switch thing.

2. During the transition only the Attitude controller of both MC and FW works. This means that for Position or Mission transitions there will be no position control during the transition. Which in its term makes prolonged transition in strong weather to be tough for the VTOL's path. So again we want a shorter transition forth and back. in order to spend less time without Position control. Mainly because intend to allow only Altitude and Position modes for flying.

[sanderux]

You keep comparing a manual control system to a position controlled system. What you are experiencing is the fact that the quadcopter is limited to a 5ms max groundspeed and you engage it while it is doing +- 12ms. You will see bad behavior from that.

I have implemented smart transition duration so it will transition back faster when you make it transition in a nose wind (it considers it complete when quadcopter cruise speed has been reached, or when the timeout occurs). If you give it a try you will notice your problems go away.

[sanderux]

Alternatively you can do active breaking as i explained in this doc: https://docs.px4.io/en/config_vtol/vtol_back_transition_tuning.html

[tubeme]

@sanderux Thanks a lot. I understand that we are engaging the MC while still in 10-12 m/s speed.

We are flying without airspeed so probably the smart transition will end when the MC cruise (ground) speed achieved. Is this in 1.7+? Or is it some other PR?

Do you know if we fly without airspeed where are the TECS getting their speed info from if it is not preset to take it from the ground speed?

[tubeme]

@sanderux I saw the smart transition is in 1.7 thanks.

[sanderux]

Without airspeed tecs doesnt know airspeed and just uses proportional scaling based on altitude