Difference between revisions of "User/AirborneCodeReorg"

From PaparazziUAV
Jump to navigation Jump to search
m
 
(33 intermediate revisions by 7 users not shown)
Line 1: Line 1:
This page summarizes the changes needed to switch from the "raw makefile in airframes" to a new "xml only aiframes" syntax
This page summarizes the changes needed to switch from the "raw makefile in airframes" to a new "xml only airframes" syntax. Just want to quickly convert your tiny/twog airframe then go [[User/AirborneCodeReorg#In_Brief|here (Brief)]]


=== Why ===
=== Why ===


# Because of its growth, paparazzi needs significant reorganization. To make this possible without breaking airframe files, the 'subsystem' idea introduced in booz is now generalized to all airframes.
Because of its growth, paparazzi needs significant reorganization. To make this possible without breaking airframe files, the 'subsystem' idea introduced in booz is now generalized to all airframes.


# A nicer looking XML structure.
# A nicer looking XML structure.
# users are not required to understand Makefile's anymore in order to choose what to compile.
# users are not required to understand Makefile's anymore in order to choose what to compile.


IMHO not really compelling reasons for such a drastical change. Better to take a look at other projects first and how they reorganized e.g. http://pixhawk.ethz.ch [OpenUAS]
Replacing the makefile section of the airframe file with xml:


==FixedWing==
# Provide a simpler to understand and consistent syntax for end users.
# Enable Paparazzi centre to provide a list of all targets for an airframe.
# Simplify the design of tools that automatically generate airframe files.
# Simplify the process of documenting the airframe file and any future additions to it.
 
The reorganization of directory structures is aimed at simplifying development and maintenance. The aim here is to provide :
 
# A consistent structure for all targets, all architectures and all subsystems.
# A structure that informs the naming of files.
# A route to enable the merging of fixed wing and rotor craft code bases.
 
 
=== Naming ===
 
In your airframe you now put '''<firmware>''' which can be 'rotorcraft', 'fixedwing' or various 'setup and testing' groups of code.
 
This code can be compiled for 1 or more '''<target>''' 's like 'ap' and 'sim'. For each target you need to define which '''board''' it runs on.
 
Strictly separating '''<firmwares>''' and '''boards''' makes it possible to re-use code, remove double files, have clear naming (booz is now the name of the board but also the name of the code, which was OK as long as there was only 1 rotorcraft board) and start running the same code on more platforms (e.g. fixed wing on lisa, rotorcraft filters on gumstix, ... etc).
 
Most users will want to run
 
  <firmware name="fixedwing">
    <target name="ap" board="tiny_2.11" />
 
or
 
  <firmware name="fixedwing">
    <target name="ap" board="twog_1.0" />
 
or
 
  <firmware name="rotorcraft">
    <target name="ap" board="booz_1.0" />
 
== FixedWing ==


===In Brief===
===In Brief===
The idea is to replace the '''<makefile>''' section with a '''<target>''' section  
The idea is to replace the '''<makefile>''' section with a '''<firmware>''' section. Just change your board type, in case of ublox 5h change 4p to 5h and remove gyro if not needed.
 
NOTE: IMHO now compiling the AC from commandline becomes more cumbersome. The makefile can already be in an '''Include''' in the XML. Do not forget it was designed this way for a reason ;). A dynamic makefile is OK by me but make sure the old methods do not break. Code refactoring is better first done by cleaning up odl thing, not redesigning first.  


Typicaly, replace:
Typicaly, replace:
Line 46: Line 79:


with
with
 
<pre>
   <firmware name="fixedwing">
   <firmware name="fixedwing">
     <target name="sim" board="pc" >
     <target name="sim" board="pc"/>
      <define name="TRAFFIC_INFO" />
    </target>
     <target name="ap" board="tiny_2.11">
     <target name="ap" board="tiny_2.11">
      <param name="FLASH_MODE" value="IAP" />
       <define name="AGR_CLIMB" />
       <define name="AGR_CLIMB" />
       <define name="LOITER_TRIM" />
       <define name="LOITER_TRIM" />
      <define name="WIND_INFO" />
      <define name="TRAFFIC_INFO" />
       <define name="ALT_KALMAN" />
       <define name="ALT_KALMAN" />
     </target>
     </target>
Line 62: Line 90:
     <!-- Communication -->
     <!-- Communication -->
     <subsystem name="telemetry" type="transparent">
     <subsystem name="telemetry" type="transparent">
       <param name="MODEM_BAUD" value="9600"/>
       <configure name="MODEM_BAUD" value="B9600"/>
     </subsystem>
     </subsystem>
     <!-- Actuators -->
     <!-- Actuators are automatically chosen according to the board-->
     <subsystem name="actuators" type="4017"/>
     <subsystem name="control"/>
     <!-- Sensors -->
     <!-- Sensors -->
     <subsystem name="gyro"/>
     <subsystem name="gyro"              type="roll"/>
     <subsystem name="attitude" type="infrared"/>
     <subsystem name="attitude" type="infrared"/>
     <subsystem name="gps" type="ublox_lea4p"/>
     <subsystem name="gps" type="ublox_lea4p"/>
     <subsystem name="navigation"/>
     <subsystem name="navigation"        type="extra"/><!--this includes OSAMNav, nav, discsurvey and nav_cube as well-->
   </firmware>
   </firmware>
   <!-- Carefull: add the location after!! -->
   <!-- Carefull: add the location after!! -->
   <makefile location="after">
   <makefile location="after">
     # specific stuff that only you are needing... be aware that files might move, so USE the firmware-source variable
     # specific stuff that only you are needing... be aware that files might move, so USE the firmware-source variable
    ap.srcs += $(FIXEDWING_SRCS)/polygon_survey.c
   </makefile>
   </makefile>
</pre>


But you can also add:
But you can also add:
Line 103: Line 131:
are now replaced by the <target> block. Notice that this name is automatically filled in paparazzi center.
are now replaced by the <target> block. Notice that this name is automatically filled in paparazzi center.


<pre>
<target name="ap" board="tiny_2.11"/>
</pre>
The FLASH_MODE is already set correctly for your board, however you can still define it (or override it with e.g. ISP for programming over the serial line):
<pre>
  <target name="ap" board="tiny_2.11">
  <target name="ap" board="tiny_2.11">
   <param name="FLASH_MODE" value="IAP"/>
   <configure name="FLASH_MODE" value="IAP"/><!-- this is already the default if not set -->
</target>
</pre>


The only field you might want to adapt depending on your configuration is the ''board'' one. The list of supported boards is  
The only field you might want to adapt depending on your configuration is the ''board'' one. The list of supported boards is  
*"twog_1"  
*"twog_1.0"  
*"tiny_2.11"
*"tiny_2.11"
*"tiny_2.1"
*"tiny_2.1"
*"tiny_1.1"
*"tiny_1.1"
*"tiny_0.99"
*"tiny_0.99"
*"booz"
*"booz_1.0"
*"lisa_l_1.0"
*"lisa_l_1.0"
*"lisa_l_1.1"
*"pc"
*"pc"


Then you should define which subsystems to use for you board. For most fixedwing Tiny users this will be standard. But for booz there are already many more options, and wait until you see the power of Lisa!
Then you should define which subsystems to use for you board. For most fixedwing Tiny users this will be standard. But for booz there are already many more options, and wait until you see the power of Lisa!


The following line defines what kind of radio control you'll be using. Fox now fixedwing doesn't have a choice and uses '''ppm'''
The following line defines what kind of radio control you'll be using. For now fixedwing doesn't have a choice and uses '''ppm'''


  <subsystem name="radio_control" type="ppm"/>
  <subsystem name="radio_control" type="ppm"/>
Line 126: Line 163:
  ap.CFLAGS += -DRADIO_CONTROL
  ap.CFLAGS += -DRADIO_CONTROL
  ap.srcs += radio_control.c $(SRC_ARCH)/ppm_hw.c
  ap.srcs += radio_control.c $(SRC_ARCH)/ppm_hw.c
=== ADC ===
'''Please remove the "adc" section as well as the adc part in the <tt>makefile</tt> section.'''
This is now configured in the [[Airframe_Configuration#Infrared|Infrared]] subsystem directly.
Formerly the "adc" section looked like this, remove it:
<section name="adc" prefix="ADC_CHANNEL_">
  <define name="IR1" value="ADC_1"/>
  <define name="IR2" value="ADC_2"/>
  <define name="IR_TOP" value="ADC_0"/>
</section>
And in the <tt>makefile</tt> section remove:
ap.CFLAGS += -DADC -DUSE_ADC_0 -DUSE_ADC_1 -DUSE_ADC_2
ap.srcs += $(SRC_ARCH)/adc_hw.c
== Available Subsystems ==
See [[Subsystems]]
[[Category:Developer_Documentation]] [[Category:Software]]

Latest revision as of 10:16, 18 March 2013

This page summarizes the changes needed to switch from the "raw makefile in airframes" to a new "xml only airframes" syntax. Just want to quickly convert your tiny/twog airframe then go here (Brief)

Why

Because of its growth, paparazzi needs significant reorganization. To make this possible without breaking airframe files, the 'subsystem' idea introduced in booz is now generalized to all airframes.

  1. A nicer looking XML structure.
  2. users are not required to understand Makefile's anymore in order to choose what to compile.

Replacing the makefile section of the airframe file with xml:

  1. Provide a simpler to understand and consistent syntax for end users.
  2. Enable Paparazzi centre to provide a list of all targets for an airframe.
  3. Simplify the design of tools that automatically generate airframe files.
  4. Simplify the process of documenting the airframe file and any future additions to it.

The reorganization of directory structures is aimed at simplifying development and maintenance. The aim here is to provide :

  1. A consistent structure for all targets, all architectures and all subsystems.
  2. A structure that informs the naming of files.
  3. A route to enable the merging of fixed wing and rotor craft code bases.


Naming

In your airframe you now put <firmware> which can be 'rotorcraft', 'fixedwing' or various 'setup and testing' groups of code.

This code can be compiled for 1 or more <target> 's like 'ap' and 'sim'. For each target you need to define which board it runs on.

Strictly separating <firmwares> and boards makes it possible to re-use code, remove double files, have clear naming (booz is now the name of the board but also the name of the code, which was OK as long as there was only 1 rotorcraft board) and start running the same code on more platforms (e.g. fixed wing on lisa, rotorcraft filters on gumstix, ... etc).

Most users will want to run

 <firmware name="fixedwing">
   <target name="ap" board="tiny_2.11" />

or

 <firmware name="fixedwing">
   <target name="ap" board="twog_1.0" />

or

 <firmware name="rotorcraft">
   <target name="ap" board="booz_1.0" />

FixedWing

In Brief

The idea is to replace the <makefile> section with a <firmware> section. Just change your board type, in case of ublox 5h change 4p to 5h and remove gyro if not needed.

Typicaly, replace:

<makefile>
 CONFIG=\"tiny_2_1_1.h\"
 include $(PAPARAZZI_SRC)/conf/autopilot/tiny.makefile
 FLASH_MODE=IAP
 ap.CFLAGS +=  -DFBW -DAP -DBOARD_CONFIG=$(CONFIG) -DLED -DTIME_LED=1
 ap.srcs = sys_time.c $(SRC_ARCH)/sys_time_hw.c $(SRC_ARCH)/armVIC.c main_fbw.c main_ap.c main.c
 ap.srcs += commands.c
 ap.CFLAGS += -DACTUATORS=\"servos_4017_hw.h\" -DSERVOS_4017
 ap.srcs += $(SRC_ARCH)/servos_4017_hw.c actuators.c
 ap.CFLAGS += -DRADIO_CONTROL
 ap.srcs += radio_control.c $(SRC_ARCH)/ppm_hw.c  
 ap.CFLAGS += -DDOWNLINK -DUSE_UART1 -DDOWNLINK_TRANSPORT=PprzTransport -DDOWNLINK_FBW_DEVICE=Uart1 -DDOWNLINK_AP_DEVICE=Uart1 -DPPRZ_UART=Uart1 -DDATALINK=PPRZ -DUART1_BAUD=B9600
 ap.srcs += downlink.c $(SRC_ARCH)/uart_hw.c datalink.c pprz_transport.c
 ap.CFLAGS += -DINTER_MCU
 ap.srcs += inter_mcu.c 
 ap.CFLAGS += -DADC -DUSE_ADC_0 -DUSE_ADC_1 -DUSE_ADC_2 -DUSE_ADC_3
 ap.srcs += $(SRC_ARCH)/adc_hw.c
 ap.CFLAGS += -DGPS -DUBX -DUSE_UART1 -DGPS_LINK=Uart1 -DUART1_BAUD=B38400
 ap.CFLAGS += -DGPS_CONFIGURE -DGPS_BAUD=38400
 ap.srcs += gps_ubx.c gps.c latlong.c
 ap.CFLAGS += -DINFRARED
 ap.srcs += infrared.c estimator.c
 ap.CFLAGS += -DNAV -DAGR_CLIMB -DLOITER_TRIM -DALT_KALMAN -DWIND_INFO
 ap.srcs += nav.c fw_h_ctl.c fw_v_ctl.c
 ap.srcs += nav_line.c nav_survey_rectangle.c
</makefile>

with

  <firmware name="fixedwing">
    <target name="sim" 			board="pc"/>
    <target name="ap" 			board="tiny_2.11">
      <define name="AGR_CLIMB" />
      <define name="LOITER_TRIM" />
      <define name="ALT_KALMAN" />
    </target>
    <subsystem name="radio_control" 	type="ppm"/>
    <!-- Communication -->
    <subsystem name="telemetry" 	type="transparent">
      <configure name="MODEM_BAUD" 		value="B9600"/>
    </subsystem>
    <!-- Actuators are automatically chosen according to the board-->
    <subsystem name="control"/>
    <!-- Sensors -->
    <subsystem name="gyro"              type="roll"/>
    <subsystem name="attitude" 		type="infrared"/>
    <subsystem name="gps" 		type="ublox_lea4p"/>
    <subsystem name="navigation"        type="extra"/><!--this includes OSAMNav, nav, discsurvey and nav_cube as well-->
  </firmware>
  <!-- Carefull: add the location after!! -->
  <makefile location="after">
    # specific stuff that only you are needing... be aware that files might move, so USE the firmware-source variable
  </makefile>

But you can also add:

 <firmware name="setup">
   <target name="tunnel" 		board="tiny_2.11" />
   <target name="setup_actuators" 	board="tiny_2.11" />
 </firmware>

In details

Let's look in more detail how this is done

You can define several <firmware> branches that are linked with you airframe

For a tiny2 this is typically the 'fixedwing' firmware. This chooses which main routine will run. In this case the fixedwing main.c

 <firmware name="fixedwing">

The old first two lines of the makefile

CONFIG=\"tiny_2_1_1.h\"
include $(PAPARAZZI_SRC)/conf/autopilot/tiny.makefile
FLASH_MODE=IAP

are now replaced by the <target> block. Notice that this name is automatically filled in paparazzi center.

 <target name="ap" board="tiny_2.11"/>

The FLASH_MODE is already set correctly for your board, however you can still define it (or override it with e.g. ISP for programming over the serial line):

 <target name="ap" board="tiny_2.11">
   <configure name="FLASH_MODE" value="IAP"/><!-- this is already the default if not set -->
 </target>

The only field you might want to adapt depending on your configuration is the board one. The list of supported boards is

  • "twog_1.0"
  • "tiny_2.11"
  • "tiny_2.1"
  • "tiny_1.1"
  • "tiny_0.99"
  • "booz_1.0"
  • "lisa_l_1.0"
  • "lisa_l_1.1"
  • "pc"

Then you should define which subsystems to use for you board. For most fixedwing Tiny users this will be standard. But for booz there are already many more options, and wait until you see the power of Lisa!

The following line defines what kind of radio control you'll be using. For now fixedwing doesn't have a choice and uses ppm

<subsystem name="radio_control" type="ppm"/>

replaces

ap.CFLAGS += -DRADIO_CONTROL
ap.srcs += radio_control.c $(SRC_ARCH)/ppm_hw.c


ADC

Please remove the "adc" section as well as the adc part in the makefile section. This is now configured in the Infrared subsystem directly.

Formerly the "adc" section looked like this, remove it:

<section name="adc" prefix="ADC_CHANNEL_">
  <define name="IR1" value="ADC_1"/>
  <define name="IR2" value="ADC_2"/>
  <define name="IR_TOP" value="ADC_0"/>
</section>

And in the makefile section remove:

ap.CFLAGS += -DADC -DUSE_ADC_0 -DUSE_ADC_1 -DUSE_ADC_2
ap.srcs += $(SRC_ARCH)/adc_hw.c

Available Subsystems

See Subsystems