Autopilot generated integration #1975

gautierhattenberger · 2016-12-19T21:33:42Z

support generated autopilot, based on rotorcraft firmware

By default the original static autopilot is used. A config flag can enable the use of the generated AP code.
A basic autopilot description is provided (4 modes + failsafe modes).
The server is capable of using the list of generated mode to properly display mode names.
Tested in NAV and GUIDED mode in sim, and direct attitude control on real aircraft.

Some extra features:

add --norc option to NPS simulator
group all system (generated) settings (AP, telemetry, modules, flight plan) under the same tab (first position)

By default the original static autopilot is used. A config flag can enable the use of the generated AP code. A basic autopilot description is provided (4 modes + failsafe modes). The server is capable of using the list of generated mode to properly display mode names. Tested in NAV and GUIDED mode in sim, and direct attitude control on real aircraft.

hooperfly · 2016-12-19T21:47:09Z

@gautierhattenberger in the case of autopilot generated modes, will there be a mechanism for finding mode/behavior indexes/offsets? For example, in the current static definition, 13 decimal is NAV and 19 decimal is GUIDED. Given that they are currently static, I use those values when binding behavior via the Flying Robot Commander. What's the plan for obtaining dynamic mode information for binding purposes?

gautierhattenberger · 2016-12-19T22:34:10Z

For now, you have to get the xml file (from the airframe file) to know the list of modes. This is how I get them for the server. For you FRC, one solution is to do the same, or if you only need a limited number of extra functionalities, we could consider adding them to the system, like changing a mode based on its name rather than its index.

flixr · 2016-12-20T14:27:21Z

sw/airborne/firmwares/rotorcraft/autopilot_utils.h

+#include "subsystems/commands.h"
+
+/** Set descent speed in failsafe mode */
+#ifndef FAILSAFE_DESCENT_SPEED


This should either be set here or in the C files, not on both locations...

flixr · 2016-12-20T14:37:06Z

sw/airborne/firmwares/rotorcraft/guidance/guidance_v.h

@@ -127,4 +145,25 @@ extern bool guidance_v_set_guided_th(float th);
    guidance_v_z_sum_err = 0;     \
  }

+#define GuidanceVSetRef(_pos, _speed, _accel) { \


Is this really needed in the header?
I would rather put this and guidance_v_z_enter in the c file...

yep, old stuff I forgot there

flixr · 2016-12-20T14:59:46Z

Regarding the syntax of the autopilot xml file:

The statements in start are separated by |. What is the advantage of this instead of simply using ;?
call actually seems to be more equivalent to call_once in the flight plan...
Maybe it would even make sense to choose a different name here, to make it clear that any statement can be used...

flixr · 2016-12-20T15:05:13Z

conf/autopilot/rotorcraft_autopilot.xml

-      <control freq="32">
+    <mode name="NAV" start="guidance_h_nav_enter()|stabilization_attitude_enter()|guidance_v_z_enter()">
+      <select cond="RCMode2() && DLModeNav()" exception="HOME"/>
+      <control freq="NAV_FREQ">
        <call fun="nav_periodic_task()"/>


So in the generated version nav_periodic_task is now only called in NAV mode, whereas in the static version it is always called (except if you are in HOME mode).

I was just lazy, I can add it again, as long as guidance is not set from nav it's fine

gautierhattenberger · 2016-12-20T17:02:20Z

For the | in init, I guess it was to make it look less "computer science". Also I was hopping to have much less functions. Maybe I could have a special child node start with one call per line.

I don't mind changing call if you have a better name.

flixr · 2016-12-20T17:11:56Z

For the | in init, I guess it was to make it look less "computer science". Also I was hopping to have much less functions. Maybe I could have a special child node start with one call per line.

| is IMHO not more readable and has the additional drawback that you can't use that operator in any of the start statements anymore...

I don't mind changing if you have a better name.

Not sure what a good name would be here, but I don't like that we use the same keyword as in the flight plan, but with different behavior.

flixr · 2016-12-20T18:49:37Z

Also maybe rename start to on_enter or so?

hooperfly · 2016-12-20T22:56:26Z

@gautierhattenberger with respect to getting a limited modes set from all modes in an autopilot, the ability to get mode by name seems like a nice feature. We just have to manage the mode name space and keep it consistent for modes across all autopilots. That seems reasonable.

…ted_integration

…nterface It can makes it easier to handle generated autopilot. Names are not matching exactly, but this can be improved in the future. An example is provided with gb2ivy program.

gautierhattenberger · 2016-12-24T00:03:42Z

@hooperfly I have added a function to fill the value index based on the 'values' list of a setting. It can makes it a bit easier to access modes. This could be improved in the future by choosing the same name and case for static and generated autopilots.

gautierhattenberger · 2016-12-29T11:09:10Z

Do you think this is fine to merge ? It should not change anything for regular users at the moment.

flixr · 2016-12-29T12:00:23Z

Except for the different semantics of call, I'm happy with this...

gautierhattenberger · 2016-12-29T15:09:43Z

Maybe the problem is FP naming after all (call -> call_loop).

Otherwise I'm suggesting for autopilots:

call -> block (I don't like this one, but it is closer to a "graphical" representation)
call -> control and previous control -> controls (why not)
call -> call_control (I think I would choose this one)
call fun=... -> fun name=... (maybe not very explicit)
call -> call_once (coherent, but one might wonder if it means that calling several time is possible)

flixr · 2016-12-29T16:51:14Z

Yeah, naming is hard... e.g. call_control is a bit weird for the on_enter functions, not sure what we should do here...
Or we merge it like it is and try to find a clearer/cleaner naming later...?

gautierhattenberger · 2016-12-29T17:20:02Z

I think the best here is call. And it is not the worst inconsistent naming (the worse being module in settings I think...).
Once the new architecture is stabilized (modules, autopilots,...) we could make a global harmonization.

gautierhattenberger added 3 commits December 19, 2016 22:07

[nps] add norc option to nps simulator

590c904

[settings] group system settings under the same tab

5166037

gautierhattenberger added Airborne Build system GCS labels Dec 19, 2016

gautierhattenberger added this to the v5.12 milestone Dec 19, 2016

gautierhattenberger requested a review from flixr December 19, 2016 21:33

gautierhattenberger added 2 commits December 20, 2016 00:03

[generator] fix xml extration error

bf174d8

remove autopilot from example file for now

1fdefb2

flixr reviewed Dec 20, 2016

View reviewed changes

gautierhattenberger added 3 commits December 20, 2016 23:35

only one definition for failsafe descent speed

9cce8a7

move macros to C file

a47f917

run flight plan nav in all modes

96370d7

gautierhattenberger added 3 commits December 21, 2016 00:31

more readable start and stop functions

34d2196

Merge remote-tracking branch 'paparazzi/master' into autopilot_genera…

6bfdf2d

…ted_integration

[python] add function to set value index by name in python settings i…

a35d637

…nterface It can makes it easier to handle generated autopilot. Names are not matching exactly, but this can be improved in the future. An example is provided with gb2ivy program.

podhrmic mentioned this pull request Dec 28, 2016

Add more selectable modes #1029

Closed

flixr merged commit 880187d into master Dec 29, 2016

flixr deleted the autopilot_generated_integration branch December 29, 2016 17:30

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Autopilot generated integration #1975

Autopilot generated integration #1975

gautierhattenberger commented Dec 19, 2016

hooperfly commented Dec 19, 2016

gautierhattenberger commented Dec 19, 2016

flixr Dec 20, 2016

gautierhattenberger Dec 23, 2016

flixr Dec 20, 2016

gautierhattenberger Dec 20, 2016

flixr commented Dec 20, 2016

flixr Dec 20, 2016

gautierhattenberger Dec 20, 2016

gautierhattenberger commented Dec 20, 2016 •

edited

Loading

flixr commented Dec 20, 2016

flixr commented Dec 20, 2016

hooperfly commented Dec 20, 2016

gautierhattenberger commented Dec 24, 2016 •

edited

Loading

gautierhattenberger commented Dec 29, 2016

flixr commented Dec 29, 2016

gautierhattenberger commented Dec 29, 2016

flixr commented Dec 29, 2016

gautierhattenberger commented Dec 29, 2016

Autopilot generated integration #1975

Autopilot generated integration #1975

Conversation

gautierhattenberger commented Dec 19, 2016

hooperfly commented Dec 19, 2016

gautierhattenberger commented Dec 19, 2016

flixr Dec 20, 2016

Choose a reason for hiding this comment

gautierhattenberger Dec 23, 2016

Choose a reason for hiding this comment

flixr Dec 20, 2016

Choose a reason for hiding this comment

gautierhattenberger Dec 20, 2016

Choose a reason for hiding this comment

flixr commented Dec 20, 2016

flixr Dec 20, 2016

Choose a reason for hiding this comment

gautierhattenberger Dec 20, 2016

Choose a reason for hiding this comment

gautierhattenberger commented Dec 20, 2016 • edited Loading

flixr commented Dec 20, 2016

flixr commented Dec 20, 2016

hooperfly commented Dec 20, 2016

gautierhattenberger commented Dec 24, 2016 • edited Loading

gautierhattenberger commented Dec 29, 2016

flixr commented Dec 29, 2016

gautierhattenberger commented Dec 29, 2016

flixr commented Dec 29, 2016

gautierhattenberger commented Dec 29, 2016

gautierhattenberger commented Dec 20, 2016 •

edited

Loading

gautierhattenberger commented Dec 24, 2016 •

edited

Loading