Difference between revisions of "AirborneCodeReorg"

From PaparazziUAV
Jump to navigation Jump to search
Line 55: Line 55:


#Move more code to modules
#Move more code to modules
#Move Makefile out of the airframe file as much as possible (modules have there own makefile / booz include makefile approach: "conf/autopilot/fixedwing_common.makefile")
#Move Makefile out of the airframe file as much as possible and replace with XML build
#Send mailing list message requesting to change the makefile section of airframes into new include structure
#Send mailing list message requesting to change the makefile section of airframes into new include structure
#Once many users have this in place and the wiki page is good, we can start to move code
#Once many users have this in place and the wiki page is good, we can start to move code
[[User:Cdewagter|cdewagter]]
 


=== Directory structure proposals ===
=== Directory structure proposals ===
Line 113: Line 113:
* booz
* booz
* lisa_l_1.0
* lisa_l_1.0
* pc


==Test Code==
==Test Code==
Line 126: Line 127:
|-
|-
|
|
   <target name="booz2_autopilot">
   <firmware name=rotorcraft>
    <subsystem name="radio_control" type="ppm"/>
    <!-- this set of firmware fits in 2 targets: -->
    <subsystem name="actuators" type="mkk"/>
    <target name="ap" board="booz">
    <subsystem name="imu" type="b2v1"/>
      <param name"FLASH_MODE" value="IAP"/>
   </target>
      <subsystem name="led" />
    </target>
    <target name="sim" board="sim" />
 
    <!-- these subsystems are used for all targets in this firmware -->
    <subsystem name="radio_control" type="ppm"/>
    <subsystem name="actuators" type="mkk"/>
    <subsystem name="imu" type="b2v1"/>
   </firmware >
 
|  
|  
include $(PAPARAZZI_SRC)/conf/autopilot/booz2_common.makefile
  include $(PAPARAZZI_SRC)/conf/autopilot/booz2_common.makefile
   include $(CFG_BOOZ)/booz2_autopilot.makefile
   include $(CFG_BOOZ)/booz2_autopilot.makefile
   include $(CFG_BOOZ)/subsystems/booz2_radio_control_ppm.makefile
   include $(CFG_BOOZ)/subsystems/booz2_radio_control_ppm.makefile
Line 141: Line 151:
   
   
put defines in here that get written in airframe.h
put defines in here that get written in airframe.h
[[User:Cdewagter|cdewagter]] I'm not really in favor of this as otherwise you might put all other data of the airframe file in here too next to the submodule it belongs too. I would suggest to only have defines that need to be in the Makefile.ac in here...
{| border=1 width=100%
{| border=1 width=100%
| airframe.xml  
| airframe.xml  
Line 147: Line 159:
|-
|-
|rowspan=4|
|rowspan=4|
<target name="booz2_autopilot">
 
    <subsystem name="actuators" type="mkk">
  <firmware name=fixedwing>
      <define name="NB" value="4"/>
    <!-- this set of firmware fits in 2 targets: -->
      <define name="ADDR" value="{ 0x52, 0x54, 0x56, 0x58 }"/>
    <target name="ap" board="tiny_2.11">
    </subsystem>  
      <param name"FLASH_MODE" value="IAP"/>
    <subsystem name="imu" type="b2v1"/>
      <define name="ALT_KALMAN"/>
   </target>
    </target>
    <subsystem name="led" />
   </firmware >
 
|-
|-
|
|
include $(PAPARAZZI_SRC)/conf/autopilot/booz2_common.makefile
  FLASH_MODE = IAP
   include $(CFG_BOOZ)/subsystems/booz2_radio_control_ppm.makefile
  include $(PAPARAZZI_SRC)/conf/board/tiny_2.11.makefile
   include $(CFG_BOOZ)/subsystems/booz2_imu_b2v1.makefile
   include $(PAPARAZZI_SRC)/conf/autopilot/fixedwing.makefile
  ap.CFLAGS += -DALT_KALMAN
   include $(SRCS_FIXEDWING)/led.makefile
|-
|-
| airframe.h
| airframe.h
|-
|-
|
|
#define ACTUATORS_MKK_NB 4
 
#define ACTUATORS_MKK_ADDR {0x52,0x54,0x56,0x58}
#define USE_LED
 
|}
|}


Line 175: Line 193:
|-
|-
|
|
   <target name="booz2_autopilot">
   <subsystem name="gps" type="ubx">
    <subsystem name="gps" type="ubx">
    <param name="GPS_UART_NR" value="1"/>
      <param name="GPS_UART_NR" value="1"/>
    <param name="GPS_BAUD"    value="38400"/>
      <param name="GPS_BAUD"    value="38400"/>
  </subsystem>  
    </subsystem>
  </target>
|
|
  GPS_UART_NR=1
  GPS_UART_NR=1
Line 278: Line 294:
Let's ask people to remove those lines from their makefile and replace with
Let's ask people to remove those lines from their makefile and replace with


   <target name="fixed_wings" board="tiny_2.11">
   <firmware name="fixedwing">
    <target name="ap" board="tiny_2.11">
     <subsystem name="radio_control" type="ppm"/>
     <subsystem name="radio_control" type="ppm"/>
   </target>
   </firmware>


which will generate the following in Makefile.ac
which will generate the following in Makefile.ac


  include $(PAPARAZZI_SRC)/conf/autopilot/fixed_wing.makefile
   include $(PAPARAZZI_SRC)/conf/boards/tiny_2.11.makefile
   include $(PAPARAZZI_SRC)/conf/boards/tiny_2.11.makefile
  include $(PAPARAZZI_SRC)/conf/autopilot/fixedwing.makefile
   include $(CFG_FIXED_WINGS)/radio_control_ppm.makefile
   include $(CFG_FIXED_WINGS)/radio_control_ppm.makefile


Line 291: Line 308:


  #define USE_RADIO_CONTROL 1
  #define USE_RADIO_CONTROL 1
#define USE_RADIO_CONTROL_PPM 1


==Outcomes (Currently in no particular order)==
==Outcomes (Currently in no particular order)==

Revision as of 23:19, 19 August 2010

Our Challenge

The current airborne sourcecode has gone a little bit out of control. Everyone was working on it enthusiastically, which is great! However, we feel now the moment has arrived where deep reorganization of the code would benefit us all.

It is really appreciated if you want to help out in this quest. Therefore remarks and suggestions can be placed on the page designed specifically for this. Of-course feel free to use the mailinglist also.

Problem areas

Fixed wing airframes have makefile directly in them - we can't change anything in the airborne code without breaking everybody's airframe

 ap.srcs += commands.c
 ap.CFLAGS += -DACTUATORS=\"servos_4015_MAT_hw.h\" -DSERVOS_4015_MAT
 ap.srcs += $(SRC_ARCH)/servos_4015_MAT_hw.c actuators.c
 ap.CFLAGS += -DRADIO_CONTROL
 ap.srcs += radio_control.c $(SRC_ARCH)/ppm_hw.c
 [...] 
 ap.CFLAGS += -DNAV -DAGR_CLIMB -DLOITER_TRIM -DALT_KALMAN -DWIND_INFO
 ap.srcs += nav.c fw_h_ctl.c fw_v_ctl.c

Booz uses "susbsystem" Makefiles

 include $(PAPARAZZI_SRC)/conf/autopilot/booz2_common.makefile
 include $(CFG_BOOZ)/booz2_autopilot.makefile
 include $(CFG_BOOZ)/subsystems/booz2_radio_control_ppm.makefile
 include $(CFG_BOOZ)/subsystems/booz2_actuators_mkk.makefile
 include $(CFG_BOOZ)/subsystems/booz2_imu_b2v1.makefile

This is the Makefile part of a booz vehicle using a booz2 IMU, mikrokopter actuators and ppm radio control

There is also the "module" facility which is very good for optional features.

There are 3 kinds of code in the airborne directory

  • generic code (that doesn't depend on any architecture or plateforme) - there's a lot of it and it should probably be sorted by type of functionalities
    • fixed_wings/main.c
    • thrust_vectoring/main.c
    • gps.[ch]
  • processor specific code (stm32, lpc21, avr, etc...)
    • arch/lpc21/uart_arch.[ch]
  • plateforme specific code (tiny, booz, lisa, etc...)
    • blaaaaa

Coding Style

Names

Booz both stands for the LPC2148 quad board and the quadrotor autopilot code - Let's call the quadrotor autopilot "Baloo" ( if you got a better name, don't hesitate, but be quick). What about a name for the fixedwing code ? (which has been called Paparazzi until now and collides with the name of the project itself )

Name proposal: Pablo (PAscal's Brainchild Lives On), also a friendly, artlike, short and possible to pronounce name

Note2: Mybe try to find name with "PA" in it to honour Pascal. Or call it somethin with "Hec" in it.The "but be quick", would be good to have a cooling period for new features and names so peple who also work on the projec but did not have the time could vote too.

Proposals and RFC

Reorganization poposed action steps

  1. Move more code to modules
  2. Move Makefile out of the airframe file as much as possible and replace with XML build
  3. Send mailing list message requesting to change the makefile section of airframes into new include structure
  4. Once many users have this in place and the wiki page is good, we can start to move code


Directory structure proposals

relative to sw/airborne

 baloo/ (a target)
 fixedwing/(or a new name, another target)
 radio_control/ (a subsystem)
 gps/ (another subsystem)
 ...(more subsystems)
 imu.[ch]
 imu/
 modules/
 arch/
   avr/
   lpc21/
   stm32/
   omap/

each susbsystem having several implementations gets a subdirectory

 imu.[ch]
 imu/
   imu_xsense.[ch]
   imu_b2.[ch]


in each of the directory under arch, a replication of the toplevel directory containing architecture specific implementations

 imu.h
 imu/
   imu_xsense.[ch]
   imu_b2.[ch]
 arch/
   lpc21/
     imu/
       imu_xsense_arch.[ch]
       imu_b2_arch.[ch]
     modules/
       demo/
         demo_arch.[ch]
   stm32/
     imu/
       imu_xsense_arch.[ch]
       imu_b2_arch.[ch]
     modules/
       demo/
         demo_arch.[ch]

supported boards

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

Test Code

Testing code is specifically for UAS of utmost importance. To test we could opt to make small cases in Testlink for everyone to try and report the outcome.

Replace makefile section with xml - [READY]

of course leave the possibility to have a makefile section, but the normal user would have something like

airframe.xml => Makefile.ac
 <firmware name=rotorcraft>
   <target name="ap" board="booz">
     <param name"FLASH_MODE" value="IAP"/>
     <subsystem name="led" />
   </target>
   <target name="sim" board="sim" />
   <subsystem name="radio_control" type="ppm"/>
   <subsystem name="actuators" type="mkk"/>
   <subsystem name="imu" type="b2v1"/>
 </firmware >
 include $(PAPARAZZI_SRC)/conf/autopilot/booz2_common.makefile
 include $(CFG_BOOZ)/booz2_autopilot.makefile
 include $(CFG_BOOZ)/subsystems/booz2_radio_control_ppm.makefile
 include $(CFG_BOOZ)/subsystems/booz2_actuators_mkk.makefile
 include $(CFG_BOOZ)/subsystems/booz2_imu_b2v1.makefile


put defines in here that get written in airframe.h cdewagter I'm not really in favor of this as otherwise you might put all other data of the airframe file in here too next to the submodule it belongs too. I would suggest to only have defines that need to be in the Makefile.ac in here...

airframe.xml => Makefile.ac
 <firmware name=fixedwing>
   <target name="ap" board="tiny_2.11">
     <param name"FLASH_MODE" value="IAP"/>
     <define name="ALT_KALMAN"/>
   </target>
   <subsystem name="led" />
 </firmware >
  FLASH_MODE = IAP
  include $(PAPARAZZI_SRC)/conf/board/tiny_2.11.makefile
  include $(PAPARAZZI_SRC)/conf/autopilot/fixedwing.makefile
  ap.CFLAGS += -DALT_KALMAN
  include $(SRCS_FIXEDWING)/led.makefile
airframe.h
  1. define USE_LED

set makefile variables

airframe.xml => Makefile.ac
 <subsystem name="gps" type="ubx">
   <param name="GPS_UART_NR" value="1"/>
   <param name="GPS_BAUD"    value="38400"/>
 </subsystem> 
GPS_UART_NR=1
GPS_BAUD=38400
include $(CFG_BOOZ)/subsystems/booz2_gps_ubx.makefile

Include guards

All headers have to be checked for missing include guards, style template:

#ifndef <MODULE>_<TARGET>_<FILENAME>_H
#define <MODULE>_<TARGET>_<FILENAME>_H
[code]
#endif /* <MODULE>_<TARGET>_<FILENAME>_H */

Example for sw/airborne/csc/airspeed.h:

#ifndef CSC_AP_AIRSPEED_H
#define CSC_AP_AIRSPEED_H
[code]
#endif /* CSC_AP_AIRSPEED_H */


Here is a list of headers know not to include guards please remove any that you update from the list.

sw/in_progress/videolizer/spook/conf_parse.h
sw/in_progress/videolizer/spook/rtp.h
sw/in_progress/videolizer/spook/stream.h
sw/in_progress/videolizer/spook/log.h
sw/in_progress/videolizer/spook/pmsg.h
sw/in_progress/videolizer/spook/global_config.h
sw/in_progress/videolizer/spook/outputs.h
sw/in_progress/videolizer/spook/jpeg_tables.h
sw/in_progress/videolizer/spook/frame.h
sw/in_progress/videolizer/spook/inputs.h
sw/in_progress/videolizer/spook/event.h
sw/in_progress/videolizer/spook/mpegaudio.h
sw/in_progress/videolizer/spook/encoders.h
sw/in_progress/videolizer/spook/base64_table.h
sw/in_progress/videolizer/spook/rtp_media.h
sw/in_progress/videolizer/wis-go7007-linux/kernel/go7007-priv.h 
sw/in_progress/videolizer/ws-go7007-linux/kernel/wis-i2c.h 
sw/in_progress/videolizer/wis-go7007-linux/include/go7007.h 
sw/in_progress/inertial/C/tilt_display.h sw/airborne/fms/packet_header.h 
sw/airborne/arm7/interrupt_hw.h 
sw/airborne/arm7/lpcusb/usbhw_lpc.h
sw/airborne/arm7/lpcusb/usbdebug.h 
sw/airborne/arm7/lpcusb/examples/console.h 
sw/airborne/arm7/lpcusb/examples/startup.h 
sw/airborne/arm7/lpcusb/examples/msc_bot.h 
sw/airborne/arm7/lpcusb/examples/spi.h 
sw/airborne/arm7/lpcusb/examples/msc_scsi.h
sw/airborne/arm7/lpcusb/examples/blockdev.h
sw/airborne/arm7/lpcusb/usbapi.h
sw/airborne/arm7/test/bootloader/console.h
sw/airborne/arm7/test/bootloader/usbhw_lpc.h
sw/airborne/arm7/test/bootloader/startup.h 
sw/airborne/arm7/test/bootloader/usbdebug.h 
sw/airborne/arm7/test/bootloader/usbapi.h 
sw/airborne/arm7/test/bootloader/lpc21iap.h 
sw/airborne/arm7/test/welcome.h 
sw/airborne/csc/csc_vane.h 
sw/airborne/csc/csc_airspeed.h 
sw/airborne/vor/lo.h 
sw/airborne/coaxial/tl_gps_configure.h 
sw/airborne/flightzone.h 
sw/airborne/booz/arch/stm32/radio_control/booz_radio_control_ppm_arch.h 
sw/airborne/sd_card/sd_card.h 
sw/airborne/ism/uart_hw.h 
sw/airborne/sim/sim_uart.h 
sw/airborne/sim/ivy_transport.h 
sw/airborne/sim/led_hw.h 
sw/airborne/osam_imu_ugear.h 
sw/airborne/wind_tunnel/wt_baro.h

Misc

  • All headers are defined relative to sw/airborne (limit the -I to -Isw/airborne and the generated code)
 #include "baloo/whatever.h"
  • Generated headers are indicated by their directory
 #include "generated/airframe.h"

Proposed methodology

[6:50:19 PM] Christophe De Wagter: "builing a new road is easy: nobody can ride until it is finished." ... "for road-works on an existing road there are 2 options: a) a non-important road can be closed for a while during roadworks b) but for roads that are too important: you need to keep a lane open: that is more work than closing it down but in the end keeps the total traffic problem minimal" [6:51:05 PM] Christophe De Wagter: I think that a gradual approach might be slightly more work, but keeps the road open and developments running.

I could not agree more!

Let's start with a subsystem that is both simple enough yet representative, I suggest radio control For now people using fixed wing have

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

Let's ask people to remove those lines from their makefile and replace with

 <firmware name="fixedwing">
   <target name="ap" board="tiny_2.11">
   <subsystem name="radio_control" type="ppm"/>
 </firmware>

which will generate the following in Makefile.ac

 include $(PAPARAZZI_SRC)/conf/boards/tiny_2.11.makefile
 include $(PAPARAZZI_SRC)/conf/autopilot/fixedwing.makefile
 include $(CFG_FIXED_WINGS)/radio_control_ppm.makefile

and the following in airframe.f

#define USE_RADIO_CONTROL 1
#define USE_RADIO_CONTROL_PPM 1

Outcomes (Currently in no particular order)

Replacing the makefile section of the airframe file with xml should:-

  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 reorganisation of directory structures is aimed at simplifying development and maintainance. 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 eventually enable the merging of fixed wing and rotor craft code bases.


available subsystems

Name type airframe(s) description
radio_control ppm FW ppm based R/C input
spektrum FW spektrum based R/C input
telemetry transparent FW, rotor to be used with any serial link replacement
xbee_api FW, rotor for XBee modems in API mode
actuators ? FW automatically select 4015 or 4017 depending on board
attitude infrared FW
gyro FW roll gyro and pitch gyro separately?
imu FW ?? or call it ahrs? but infrared are not an ahrs...
gps ublox_lea5h FW
ublox_lea4p FW
skytraq FW
airspeed ets FW Eagle Tree Systems airspeed and baro sensor
navigation common FW or no type for standard nav?

Some of this subsystems could be moved to modules to limit the number of #ifdef in main_ap

Proposition for Slight Change to give better meanings to XML-tags and accommodate more targets in an airframe

Proposition:

 <airframe>
   <firmware name=fixedwing>
     <target name=ap board="tiny2.11">
       <param name"FLASH_MODE" value="IAP"/>
       <subsystem name="led" />
     </target>
     <target name=sim board = "sim" />
     <subsystem name="navigation" />
   </firmware >
   <firmware name=tunnel>
     <target="tunnel" board="tiny" />
   </firmware>
 </airframe>