Suggestions

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Suggestions

antoine drouin
Hello world

I've been using Paparazzi's control laws (5.0.0) as benchmark and while doing so, a couple of things bugged me that i though i might share:

For rotorcraft, it wasn't too hard to isolate control laws except for minor details:
 
  sw/airborne/firmware/stabilization/stabilization_attitude_rc_setpoint.c pulls autopilot_mode, guidance_h_mode, transition_theta_offset
   
  USE_FMS is only used in sw/airborne/firmwares/rotorcraft/guidance/guidance_v and nowhere else, it could probably be removed

   sw/airborne/firmwares/rotorcraft/guidance/guidance_v.c includes nav... that seems to be backward


For fixedwing, it was much harder, the weight of history is being heavily felt...
    
  firmwares/fixedwing/stabilization/stabilization_attitude.c includes both "autopilot.h" and CTRL_TYPE_H (which is... the type of vertical guidance and can be either  guidance_v.h,  guidance_v_n.h or energy_ctrl.h)

  firmwares/fixedwing/guidance/energy_control get its' accelerations directly from imu, maybe it would benefit from using the state interface
  it also uses "launch" and "kill_throttle" from autopilot.h. Shouldn't those be part of state? (at least launch, which is the airborne status of the vehicle and is called in_flight in the rotorcraft version)


I'll stop here for now. Let me know if you're interested in more

Regards

Poine 




_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: Suggestions

bruno jouvencel
Hello Antoine

Thank you for specifying what you want to do.

best regards

--
Bruno Jouvencel

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: Suggestions

Michal Podhradsky
Hi Poine,

we are working on RT Paparazzi (you can check out the current branch (https://github.com/paparazzi/paparazzi/tree/rt_paparazzi) and we currently have real time rotorcraft firmware. Partially because the code and control loops was designed in quite a neat way.

However, now we are developing real time fixedwing firmware and you are right, the burden of history is present. The best way to fix this would be refactoring the fixedwing code (e.g. autopilot structure, control loops etc.) to follow similar style as rotorcraft.

Benefits are way clearer code, possibly performance improvements and also easier change of the control loops/navigation routines (imagine you want to use your own control loop). Unfortunately it is a lot of work and lot of the code will have to be marked as obsolete.

I started with the refactoring, once I am far enough I am happy to share, in the meantime I would appreciate suggestions/thoughts on the idea.

Regards
Michal


On Tue, Dec 10, 2013 at 7:14 PM, bruno jouvencel <[hidden email]> wrote:
Hello Antoine

Thank you for specifying what you want to do.

best regards

--
Bruno Jouvencel

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel



_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: Suggestions

Ben Laurie
On 12 December 2013 08:59, Michal Podhradsky
<[hidden email]> wrote:
> Hi Poine,
>
> we are working on RT Paparazzi (you can check out the current branch
> (https://github.com/paparazzi/paparazzi/tree/rt_paparazzi) and we currently
> have real time rotorcraft firmware. Partially because the code and control
> loops was designed in quite a neat way.

Curious: why is existing Paparazzi not RT?

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: Suggestions

Tilman Baumann-3
On 12/12/13 10:53, Ben Laurie wrote:
> On 12 December 2013 08:59, Michal Podhradsky
> <[hidden email]> wrote:
>> Hi Poine,
>>
>> we are working on RT Paparazzi (you can check out the current branch
>> (https://github.com/paparazzi/paparazzi/tree/rt_paparazzi) and we currently
>> have real time rotorcraft firmware. Partially because the code and control
>> loops was designed in quite a neat way.
> Curious: why is existing Paparazzi not RT?
It kind of is. It is designed similarly to the moon lander software. It
runs a list of functions at a fixed interval. The important ones first
the less important ones later.
If it can not finish execution of that list in time it will just start
over at the beginning of the list. This way the important functions can
not starve.

What the paparazzi_rt guys seemed to have done is to port the system to
a 'real' real-time operating system (ChibiOS).
To be honest, this was lacking in the paparazzi design for a long time.
The 'old' way of doing realtime was ok, bit with increasingly more
powerful CPU and the demand to run all sorts of other functions on the
same chip a proper realtime OS would help a lot.
I haven't looked into how much they achieved and how ambitious they do
it. You could just run ppz in one or two tasks (ap and fbw) and keep the
internal interval scheduler. Or you could split all internal ppz tasks
into Chibi tasks...


PS: Sorry this was a very high level view. Hope that it what you where
after.

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: Suggestions

Tilman Baumann-3
On 12/12/13 11:03, Tilman Baumann wrote:

> On 12/12/13 10:53, Ben Laurie wrote:
>> On 12 December 2013 08:59, Michal Podhradsky
>> <[hidden email]> wrote:
>>> Hi Poine,
>>>
>>> we are working on RT Paparazzi (you can check out the current branch
>>> (https://github.com/paparazzi/paparazzi/tree/rt_paparazzi) and we currently
>>> have real time rotorcraft firmware. Partially because the code and control
>>> loops was designed in quite a neat way.
>> Curious: why is existing Paparazzi not RT?
> It kind of is. It is designed similarly to the moon lander software. It
> runs a list of functions at a fixed interval. The important ones first
> the less important ones later.
> If it can not finish execution of that list in time it will just start
> over at the beginning of the list. This way the important functions can
> not starve.

Btw. Totally worth reading up on Apollos 1202 program alarm. ;)
It was exactly this kind of condition. Not all periodic tasks fit into
the time slot and less important ones where skipped.

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: Suggestions

Hwarm
In reply to this post by Ben Laurie
Hi,
we make first experiments with RT  nuttx and  STM discoveryf4 .
For nuttx also a lpc2148 port exist.
The GCC 4.7 perform the floating point hardware.
It seems that other groups  (ETH)  use also this RT-OS and leave  (ChibiOS).
I don't know why they change from ChibiOS to nuttx RT-OS.
Perhaps there is more middle ware for free  (FAT, USB-host, SD,CAN, Ether net) etc.

Heinrich

 

Ben Laurie schrieb:
On 12 December 2013 08:59, Michal Podhradsky
[hidden email] wrote:
  
Hi Poine,

we are working on RT Paparazzi (you can check out the current branch
(https://github.com/paparazzi/paparazzi/tree/rt_paparazzi) and we currently
have real time rotorcraft firmware. Partially because the code and control
loops was designed in quite a neat way.
    

Curious: why is existing Paparazzi not RT?

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

  

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: Suggestions

Ben Laurie
In reply to this post by Tilman Baumann-3
On 12 December 2013 11:03, Tilman Baumann <[hidden email]> wrote:

> On 12/12/13 10:53, Ben Laurie wrote:
>> On 12 December 2013 08:59, Michal Podhradsky
>> <[hidden email]> wrote:
>>> Hi Poine,
>>>
>>> we are working on RT Paparazzi (you can check out the current branch
>>> (https://github.com/paparazzi/paparazzi/tree/rt_paparazzi) and we currently
>>> have real time rotorcraft firmware. Partially because the code and control
>>> loops was designed in quite a neat way.
>> Curious: why is existing Paparazzi not RT?
> It kind of is. It is designed similarly to the moon lander software. It
> runs a list of functions at a fixed interval. The important ones first
> the less important ones later.
> If it can not finish execution of that list in time it will just start
> over at the beginning of the list. This way the important functions can
> not starve.
>
> What the paparazzi_rt guys seemed to have done is to port the system to
> a 'real' real-time operating system (ChibiOS).
> To be honest, this was lacking in the paparazzi design for a long time.
> The 'old' way of doing realtime was ok, bit with increasingly more
> powerful CPU and the demand to run all sorts of other functions on the
> same chip a proper realtime OS would help a lot.
> I haven't looked into how much they achieved and how ambitious they do
> it. You could just run ppz in one or two tasks (ap and fbw) and keep the
> internal interval scheduler. Or you could split all internal ppz tasks
> into Chibi tasks...
>
>
> PS: Sorry this was a very high level view. Hope that it what you where
> after.

No, that was exactly what I was after. Interesting.

Back when I worked in embedded systems (quite a while ago now), we
didn't like real-time operating systems and preferred the approach
taken by Paparazzi. This is because the cost of context switches in RT
OSes is very high compared to the cost of function calls and
occasional timer checks...

>
> _______________________________________________
> Paparazzi-devel mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: Suggestions

Alexandre Bustico
Le 13/12/2013 14:28, Ben Laurie a écrit :
> This is because the cost of context switches in RT
> OSes is very high compared to the cost of function calls and
> occasional timer checks...

With chibios on stm32f4, context switching @ 1khz in the worst case :
using hardware float unit (so that float registers have to be saved),
have a cost of 0.1%, so 99.9% for your tasks, 0,1% for the system, when
you are in position where you miss theses 0.1%, you're in big trouble :-)

"big" mcu, are designed for rtos, there is dedicated timer for the
systick, and dedicated hardware for making context switch easy and fast.

--
Alexandre


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: Suggestions

Alexandre Bustico
In reply to this post by Hwarm
Le 13/12/2013 12:37, Prof. Dr.-Ing. Heinrich Warmers a écrit :
> It seems that other groups  (ETH)  use also this RT-OS and leave
> (ChibiOS).
> I don't know why they change from ChibiOS to nuttx RT-OS.

there is pro and cons for both theses two great rtos.

nuttx pro :
° has a posix api : those who come from unix land will fell familiar
with the api, it's also easier to port unix tool to nuttx

nuttx cons:
° target high end mcu, has a large footprint and use more resources.

chibios pro :
° low overhead, low footprint, static declaration of resources used

chibios cons:
° specific api, slow learning curve because of a difficult to understand
documentation

> Perhaps there is more middle ware for free  (FAT, USB-host, SD,CAN,
> Ether net) etc.
>

chibios come with a nearly complete hardware library abstraction layer,
(only misses some  things like slave implementation for
i2c ans spi buses), it already come with fatfs, lwip, sd support above
spi and sdio, etc etc.

--
Alexandre


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: Suggestions

antoine drouin
Paparazzi was designed with a hardware layer abstraction (except when it wasn't, see https://github.com/paparazzi/paparazzi/blob/master/sw/airborne/firmwares/fixedwing/main_ap.c line 255)

The problems I was mentioning at the beginning of this thread have nothing to do with hardware abstraction, though.

Poine


On Fri, Dec 13, 2013 at 2:52 PM, Alexandre Bustico <[hidden email]> wrote:
Le 13/12/2013 12:37, Prof. Dr.-Ing. Heinrich Warmers a écrit :

It seems that other groups  (ETH)  use also this RT-OS and leave (ChibiOS).
I don't know why they change from ChibiOS to nuttx RT-OS.

there is pro and cons for both theses two great rtos.

nuttx pro :
° has a posix api : those who come from unix land will fell familiar with the api, it's also easier to port unix tool to nuttx

nuttx cons:
° target high end mcu, has a large footprint and use more resources.

chibios pro :
° low overhead, low footprint, static declaration of resources used

chibios cons:
° specific api, slow learning curve because of a difficult to understand documentation


Perhaps there is more middle ware for free  (FAT, USB-host, SD,CAN, Ether net) etc.


chibios come with a nearly complete hardware library abstraction layer, (only misses some  things like slave implementation for
i2c ans spi buses), it already come with fatfs, lwip, sd support above spi and sdio, etc etc.

--
Alexandre



_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: Suggestions

Ben Laurie
In reply to this post by Alexandre Bustico
On 13 December 2013 13:40, Alexandre Bustico
<[hidden email]> wrote:

> Le 13/12/2013 14:28, Ben Laurie a écrit :
>
>> This is because the cost of context switches in RT
>> OSes is very high compared to the cost of function calls and
>> occasional timer checks...
>
>
> With chibios on stm32f4, context switching @ 1khz in the worst case : using
> hardware float unit (so that float registers have to be saved),
> have a cost of 0.1%, so 99.9% for your tasks, 0,1% for the system, when you
> are in position where you miss theses 0.1%, you're in big trouble :-)

Process switching is not the only context switching, of course -
interrupts also cause context switches (and we used to avoid those,
too). But, to be fair, Paparazzi on Linux still uses h/w interrupts...

> "big" mcu, are designed for rtos, there is dedicated timer for the systick,
> and dedicated hardware for making context switch easy and fast.
>
> --
> Alexandre
>
>
>
> _______________________________________________
> Paparazzi-devel mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: Suggestions

flixr
Administrator
In reply to this post by antoine drouin
Hi Antoine,

just came back from 2 weeks of vacation and hence didn't answer earlier...

I've been using Paparazzi's control laws (5.0.0) as benchmark and while doing so, a couple of things bugged me that i though i might share:

 Thanks!

For rotorcraft, it wasn't too hard to isolate control laws except for minor details:
 
  sw/airborne/firmware/stabilization/stabilization_attitude_rc_setpoint.c pulls autopilot_mode, guidance_h_mode, transition_theta_offset

Not nice indeed, patches welcome... also added an issue about it so we don't forget: https://github.com/paparazzi/paparazzi/issues/599

   
  USE_FMS is only used in sw/airborne/firmwares/rotorcraft/guidance/guidance_v and nowhere else, it could probably be removed

 Jep, removed in master.

   sw/airborne/firmwares/rotorcraft/guidance/guidance_v.c includes nav... that seems to be backward

Yes, it is backwards... just like in a couple of other places where the setpoint values are read from a global var of a "higher" subsystem instead of calling a function to set the setpoint in the "higher" system (in this case nav).

I guess a better solution would be get rid of GUIDANCE_V_MODE_NAV, GUIDANCE_V_MODE_RC_CLIMB, etc. and only have 3 modes in the end regardless of where the setpoint is coming from:
- GUIDANCE_V_MODE_MANUAL|DIRECT: direct throttle setpoint
- GUIDANCE_V_MODE_CLIMB|SPEED: vertical speed setpoint
- GUIDANCE_V_MODE_ALT|POS: altitude (vertical pos) setpoint

And then set the setpoints according to vertical_mode in nav_run if in NAV mode...
In the end we should revisit the complete (autopilot/guidance) mode system anyway, but no one volunteered for this bigger task so far (lack of time).
Or do you have any other ideas?

For fixedwing, it was much harder, the weight of history is being heavily felt...
    
  firmwares/fixedwing/stabilization/stabilization_attitude.c includes both "autopilot.h" and CTRL_TYPE_H (which is... the type of vertical guidance and can be either  guidance_v.h,  guidance_v_n.h or energy_ctrl.h)

Jep, complete fixedwing control loops need refactoring and cleanup... also a bigger task...
Patches/pull requests very welcome!
 
  firmwares/fixedwing/guidance/energy_control get its' accelerations directly from imu, maybe it would benefit from using the state interface

Currently acceleration can only be read in "fixed" world coordinates from the state interface: http://docs.paparazziuav.org/latest/group__state__acceleration.html
Also it is not actually set with all the INS implementations (e.g. not with the fixedwing ins alt_float).
I'm not sure if it really makes sense to add acceleration in body frame to the state interface, as we currently don't have any filters estimating it (the INS subsystems estimate accel in world frame).
But maybe it would make sense to read the acceleration in NED from the state interface and rotate it to body frame? Or even add this as a get function to the state interface?
@Christophe, you wrote the energy_control, what do you think?
 
  it also uses "launch" and "kill_throttle" from autopilot.h. Shouldn't those be part of state? (at least launch, which is the airborne status of the vehicle and is called in_flight in the rotorcraft version)

I guess it might make sense to add an airborne status to the state interface to replace launch and in_flight.
The question then is of course if a boolean airborne flag this is enough for the state interface (and other states like motors_on, takeoff, landing, should be handled in separate state machines).

I'll stop here for now. Let me know if you're interested in more

Please keep it coming ;-)

Cheers, Felix


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel