AirborneCodeReorg

From PaparazziUAV
Revision as of 15:36, 16 August 2010 by Esden (talk | contribs)
Jump to navigation Jump to search

Problem statement

Current airborne code has gone a little bit out of control and is in deep need of a reorganization.

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
  • processor specific code (stm32, lpc21, avr, etc...)
  • plateforme specific code (tiny, booz, lisa, etc...)

Coding Style

Proposed reorganization

  1. Move more code to modules
  2. 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")
  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

cdewagter


Replace makefile section with xml

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

airframe.xml => Makefile.ac
 <target name="booz2_autopilot">
    <subsystem name="radio_control" type="ppm"/>
    <subsystem name="actuators" type="mkk"/>
    <subsystem name="imu" type="b2v1"/>
 </target>
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

airframe.xml => Makefile.ac
<target name="booz2_autopilot">
    <subsystem name="actuators" type="mkk">
      <define name="NB" value="4"/>
      <define name="ADDR" value="{ 0x52, 0x54, 0x56, 0x58 }"/>
    </subsystem> 
    <subsystem name="imu" type="b2v1"/>
 </target>
include $(PAPARAZZI_SRC)/conf/autopilot/booz2_common.makefile
  include $(CFG_BOOZ)/subsystems/booz2_radio_control_ppm.makefile
  include $(CFG_BOOZ)/subsystems/booz2_imu_b2v1.makefile
airframe.h
#define ACTUATORS_MKK_NB 4
#define ACTUATORS_MKK_ADDR {0x52,0x54,0x56,0x58}

set makefile variables

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

Inculde guards

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

#ifndef <MODULE>_<TARGET>_<FILENAME>_H
#define <MODULE>_<TARGET>_<FILENAME>_H

#endif /* <MODULE>_<TARGET>_<FILENAME>_H */

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

#ifndef CSC_AP_AIRSPEED_H
#define CSC_AP_AIRSPEED_H

#endif /* CSC_AP_AIRSPEED_H */

Misc

  • All headers are defined relative to sw/airborne
  • Generated headers are indicated by their directory
 #include "generated/airframe.h"