Re: [Paparazzi-devel] problem with rotorcraft vertical guidance

[alonso acuña]

Yes probably a  convenience function would be best.  I am unsure now about what exactly is the difference in resetting the altitude reference and setting the GuidanceV reference to current altitude. Could you please comment on this?

On Tue, Jun 24, 2014 at 4:06 PM, Felix Ruess <address@hidden> wrote:

Hi,

in master you can already use <call fun="nav_set_heading_current()"/> instead of <set value="stateGetNedToBodyEulers_i()->psi" var="nav_heading"/>...

I don't think that setting the altitude reference (local coordinate system) to current altitude will suit all users, so maybe rather something like GuidanceVSetRef(stateGetPositionNed_i()->z, 0, 0) ?

Or rather one convenience function that does both of the above?

Cheers, Felix

On Tue, Jun 24, 2014 at 6:19 AM, alonso acuña <address@hidden> wrote:

Hi. I think the Takeoff block should have a GuidanceVSetRef(0,0,0)  . Some changes are needed for this to work. This would make sure to start from 0 even if previously the reference was set to other value by clicking another block or from a previous entrance to the Takeoff block which did not actually produce a takeoff because of kill switch, motors not armed etc.  Given that most users are not even aware of the altitude reference concept they would expect everything to work when clicking the takeoff button again, regardless of what happened before.

For that same reason probably a call to GuidanceVSetRef would be confusing and could cause even more trouble if someone changes the parameters. So I think we need to add something that will reset the ref without further trouble to the user.

After all the changes to make the take off safer it has become very complicated:

  <block name="Takeoff" strip_button="Takeoff" strip_icon="takeoff.png">

      <exception cond="stateGetPositionEnu_f()->z > 4" deroute="Standby"/>

      <set value="stateGetNedToBodyEulers_i()->psi" var="nav_heading"/>

      <call fun="NavSetWaypointHere(WP_CLIMB)"/>

      <call fun="NavSetAltitudeReferenceHere()"/>

      <call fun="GuidanceVSetRef(0,0,0)"/>

      <stay climb="0.5" vmode="climb" wp="CLIMB"/>

    </block>

On Wed, Jun 18, 2014 at 4:12 PM, Felix Ruess <address@hidden> wrote:

Hi Alonso,

as already noted in the previous mail, limiting the throttle via RC was actually only meant for emergencies and in normal operation you should give max throttle before takeoff.

You have to keep in mind that we currently don't have a "real" velocity control mode (that would also mean more tuning parameters) but also use the position/altitude control mode for this and "simply" advance the reference and setpoint with a desired speed.

However you are of course right that the "climb" mode does not handle this situation well. Please see https://github.com/paparazzi/paparazzi/pull/754 which proposes a limit (GUIDANCE_V_REF_MAX_Z_DIFF with default of 2m) to how far the z_ref can advance from current altitude in climb mode. This is probably not an ideal solution, but should at least help a lot.

Cheers, Felix

On Wed, Jun 18, 2014 at 7:46 AM, alonso acuña <address@hidden> wrote:

Hello. There is a problem in the way the altitude reference (desired altitude) is set when vmode is climb. This causes a situation where the aircraft takes off but then comes down when going to the STDBY point.

In the takeoff block we have <stay climb="0.5" vmode="climb" wp="CLIMB"/>

The problem is that the gv_z_ref variable is allowed to drift arbitrarily from the current altitude. So for example if the throttle is set to 0 in the RC the aircraft will not move but the desired altitude increases continuously. Once the throttle is increased and it goes to sufficient altitude to move into the Standby block the speed is set using the difference from the gv_z_ref to the new target altitude. The actual altitude is not taken into account. So this means that for example if the throttle was at 0 for enough time to allow the gv_z_ref to go to 30m and the STBDY is at 5m and the aircraft is at 2m, the speed is set for descent from 30 to 5m, which quickly makes the aircraft come back to the ground.

I am not sure if this is a general error and the entire reference calculation needs to be fixed or just a special case needs to be made for the takeoff.  There could be other situations, for example if the aircraft is in the air and the motors are not giving enough thrust to achieve the desired climb speed the gv_z_ref could go very high and then make the aircraft come down when it should be going up to a higher target altitude.

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel