Difference between revisions of "AirborneCodeReorg"
(removed outcomes as that is on the user page) |
(move available subsytems to user page) |
||
Line 337: | Line 337: | ||
#define USE_RADIO_CONTROL 1 | #define USE_RADIO_CONTROL 1 | ||
#define USE_RADIO_CONTROL_PPM 1 | #define USE_RADIO_CONTROL_PPM 1 | ||
Revision as of 15:24, 26 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
- fixedwing/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
- Move more code to modules
- 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
- 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]
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"/> </target> <target name="sim" board="sim" /> <subsystem name="radio_control" type="ppm"/> <subsystem name="actuators" type="mkk"/> <subsystem name="imu" type="b2v1"/> </firmware > <firmware name="setup" > <target name="tunnel" /> <target name="test_actuators" /> </firmware> |
ifeq ($(TARGET),ap) include $(PAPARAZZI_SRC)/conf/board/booz.makefile include $(PAPARAZZI_SRC)/conf/autopilot/rotorcraft.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 endif ifeq ($(TARGET),sim) include $(PAPARAZZI_SRC)/conf/board/pc.makefile include $(PAPARAZZI_SRC)/conf/autopilot/rotorcraft.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 endif ifeq ($(TARGET),tunnel) include $(PAPARAZZI_SRC)/conf/board/booz.makefile include $(PAPARAZZI_SRC)/conf/autopilot/setup.makefile endif |
?? put defines in here that get written in airframe.h ??
cdewagter I'm not really sure this is needed as otherwise you might put all other data of the airframe file in here too next to the submodule it belongs too. I think it is more readable with less defines in here. I would suggest to only have global compile defines that need to be in the Makefile.ac 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 | ||
#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 |
- Note that now a subsystem can be enabled for all targets in that firmware by using
$(TARGET).srcs += navigation.c
- Note that you only 1 time in the board file (e.g. /boards/tiny_2.11.makefile)
$(TARGET).arch = arm7
instead having this in the firmware/subsystem makefiles
tunnel.ARCH = arm7 ap.ARCH = arm7 fbw.ARCH = arm7 ...
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