THIS MEANS YOU MUST RETUNE YOUR PID LOOP IF YOU'RE FLYING WITH IT
Alternatively divide Kd by 1000 and multiply Ki by 1000
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1782 ebee16cc-31ac-478f-84a7-5cbb03baadba
Flight: Create PositionDesired (the active waypoint) UAVObject and make the FlightSituationActual no update since it not used.
Flight: New velocity desired object that passes information between the look computing the desired velocity and the PID loop to get it (updated at different rates)
UAVObjects/PositionActual: Remove unused GPS fields
UAVObjects/PositionActual VelocityActual: Split the velocity into a separate object. ALso make sure all the information telemetered around is in cm to avoid using floats.
UAVObject/GuidanceSettings: New guidance settings object for the guidance module
Flight/Posix: Add the new objects to the Posix sim
Flight/Guidance: Computes a desired velocity based on position error than runs a PID loop to control roll and pitch to achieve that velocity. All distances are in cm, and updated the PositionActual fields to reflect this and use int32.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1760 ebee16cc-31ac-478f-84a7-5cbb03baadba
determine retransmitting calibration, home location and such.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1755 ebee16cc-31ac-478f-84a7-5cbb03baadba
Calibration should take less time now too (using second moments to estimate
variance in one pass). Now need to change to multiple messages to get the
calibration in to keep the request message size minimal. Also currently
running sensor calibrate doesn't store the gyro bias so if you want to use this
you'll have to tweak it manually. I'll fix that step tomorrow.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1741 ebee16cc-31ac-478f-84a7-5cbb03baadba
The system settings UAVObject is updated, you will have to recompile your firmware. If you want to take a look and let me know, please do!
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1737 ebee16cc-31ac-478f-84a7-5cbb03baadba
Removing some Experimental and Incomplete Modules and their UAVObjects not suited for 1.0
- they will be moved into an experimental branch:
Navigation : experimental code only
FlightSituation: experimental code only
Guidance : preliminary draft - possibly to be replaced by peabody124 position hold code if finished in time.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1729 ebee16cc-31ac-478f-84a7-5cbb03baadba
Creating GuidanceModule together with PositionDesired UAVObject (as discussed),
so dschin and me can work on it :-)
Will compile and (on sim_posix) execute, but PID logic is yet untested and preliminary.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1722 ebee16cc-31ac-478f-84a7-5cbb03baadba
This is functionally the same as having a heading hold gyro in hardware.
Code is copied from the simple stabilisation routine and is a bit rough at the minute, but initial testing looks good.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1670 ebee16cc-31ac-478f-84a7-5cbb03baadba
The EOC EXTI interrupt configuration was incorrectly
pointing at GPIOG pin 8 rather than GPIOC pin 15.
This was preventing the EOC interrupt from working
properly.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1626 ebee16cc-31ac-478f-84a7-5cbb03baadba
Change from using vTaskDelay to using vTaskDelayUntil to
ensure that we're trying to stay periodic rather than
just waiting a fixed amount of time after each loop of
processing.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1580 ebee16cc-31ac-478f-84a7-5cbb03baadba
No functional changes.
The closing comment on some of the USB_HID related
ifdefs was outdated. Fixed.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1541 ebee16cc-31ac-478f-84a7-5cbb03baadba
The resultant error could range from -360º -> +360º
Since this is only used for Helicopters / multi rotors, and the aircraft can rotate in any direction, I added the modulo logic so that it is now from -180º -> +180º this should now take quickest path to correct the error.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1464 ebee16cc-31ac-478f-84a7-5cbb03baadba
The Wiki (http://wiki.openpilot.org/Unit_Standards) states this should be 0 - 360º
Made the code match the wiki.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1463 ebee16cc-31ac-478f-84a7-5cbb03baadba
This creates a new UAVObject called GPSSatellites to hold
information about which satellites the GPS receiver can see
and the quality of their signals.
NMEA GSV sentences are now parsed. The full set of GSV data
may be split across multiple GSV sentences, each containing
info for at most 4 satellites. Once an entire set of GSV
records has been collected, the GPSSatellites UAVObject is
updated.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1453 ebee16cc-31ac-478f-84a7-5cbb03baadba
Remove asserts on bad data, only assert on coding errors.
Remove unnecessary inline qualifier to reduce code size.
Handle more lat/lon precisions in conversion to fixed-point.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1452 ebee16cc-31ac-478f-84a7-5cbb03baadba
Change from spaces to <TAB> to match the formatting in
the template. No functional changes, just whitespace.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1451 ebee16cc-31ac-478f-84a7-5cbb03baadba
GPS module now updates GPSPosition UAVObject
rather than the PositionActual object. The
GPSPosition object is intended to be consumed
only by the AHRS. The AHRS will use this (and
other inputs) to compute a filtered version of
the position in the PositionActual object.
This commit will cause temporary breakage of the
GPS functionality in the GCS until the PositionActual
object is properly updated by the AHRS. Most of the
GCS should continue to use PositionActual. The only
exception to this might be any tool for specifically
visualizing the raw GPS state.
GPS.c is now only responsible for receiving a
complete NMEA sentence from the COM interface.
NMEA parsing is now factored out into NMEA.[ch]
which is where GPSPosition is now updated based
on the complete NMEA sentences obtained from the
GPS.
Latitude and Longitude are now encoded in a
fixed-point notation in units of degrees x 10^-7
to prevent truncation of precision due to encoding
into a float.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1431 ebee16cc-31ac-478f-84a7-5cbb03baadba
No functional changes. Whitespace/tab fixups only.
Use TRUE/FALSE instead of 1/0.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1430 ebee16cc-31ac-478f-84a7-5cbb03baadba
Since there are a lot of autogenerated changes the important ones are:
flight/OpenPilot/UAVObjects/inc/uavobjecttemplate.h - added description and define to make the ObjectReadOnly query
flight/OpenPilot/UAVObjects/uavobjecttemplate.c
flight/OpenPilot/UAVObjects/uavobjectmanager.c - added the UAVObjReadOnly query
ground/src/libs/uavobjgenerator/uavobjectparser.cpp - added parsing of description field
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1425 ebee16cc-31ac-478f-84a7-5cbb03baadba
This has throttle and pitch curves implemented and can be configured for many swashplate configurations.
This has flown a 450 clone (with training wheels) and the ccpm worked well.
Still need to neaten up some stuff and work out how to implement yaw stabilisation in manual mode.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1412 ebee16cc-31ac-478f-84a7-5cbb03baadba
1. Added reenumeration function and call it on USB init (device will appear after reprogramming now)
2. Moved buffer.c to general flight/Libraries location
3. Removed the 62 byte transmission limitation by adding a transmission buffer
4. Sped up USB communication by increasing endpoint polling frequency
Note, that the nonblocking and blocking USB send functions are not blocking entirely correcting. The blocking calls the nonblocking, and the nonblocking blocks until the last chunk has started tranmission if it's a big transmission. The buffering I added would generalize to non-blocking nicely, but would require using the EP1(IN) callback to handle most of the tranmission. This creates a lot of issues if one function is pushing data onto the buffer and the interrupt is sending.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1403 ebee16cc-31ac-478f-84a7-5cbb03baadba
Adding settings for configuring CCPM mixing for Helicopters to ActuatorSettings and SystemSettings UAVObjects.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1402 ebee16cc-31ac-478f-84a7-5cbb03baadba
This object is not yet populated or used. This
will soon hold the raw position data from the GPS
receiver. PositionActual will be converted to
hold the computed position from the AHRS.
Contents of this object are still subject to change.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1355 ebee16cc-31ac-478f-84a7-5cbb03baadba
This is to align the object names to matches the UAVObject
architecture doc. No functional changes.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1351 ebee16cc-31ac-478f-84a7-5cbb03baadba
into NED reference frame and used in the INSGPS algorithm, although currently this
information isn't propagated back to OP. Data structures related to the GPS position
into the algorithm and the position estimate out will likely be in flux.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1334 ebee16cc-31ac-478f-84a7-5cbb03baadba
Altitude/pressure sensor data is sent to the AHRS whenever
the AltitudeActual object is updated.
Altitude, Pressure and Temperature are sent as floats.
Same as in the UAVObject that goes to the GCS.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1291 ebee16cc-31ac-478f-84a7-5cbb03baadba
No functional change, uavobjects were not regenerated since last
change to the object generator.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1288 ebee16cc-31ac-478f-84a7-5cbb03baadba
The STM32 I2C block has a number of errata associated with it.
These errata are primarily related to timing sensitivities between
the peripheral and the interrupt handler. In particular, the
correct generation of the stop bit relies on the I2C IRQ running
immediately and not being held off for any reason.
NOTE: The I2C interrupts must be the highest priority IRQs in the
system to ensure correct operation.
I2C protocol is now implemented as a formal state machine.
See: stm32_i2c_fsm.{dot,jpg} for FSM description.
I2C init is now expressed by const initializers in pios_board.c
for both OP and AHRS boards.
I2C device drivers (ie. bmp085/hmc5843) now pass in const arrays
of an unlimited number of bus transfers to be done atomically.
The I2C adapter driver now handles all bus-level locking across the
list of transactions. Generation of start/restart/stop conditions
are handled automatically over the list of transactions.
Timeouts have been removed from the API for now. May be added
back later.
This driver has run error free on both the OP and AHRS boards for
up to 48hrs but it still sometimes fails earlier than that on the OP
board. There is another possible set of improvements to the driver
that could employ the DMA engine for transfers of >= 2bytes. This
change would reduce the timing sensitivities between the peripheral
and the driver but unfortunately, both the SPI and I2C interfaces
share the DMA1 engine. That means only one of these two peripherals
can use the DMA engine and right now, SPI between OP and AHRS is
already using it.
Failures are currently fatal and will lock up the CPU. This allows
useful information to be obtained in the failure cases.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1241 ebee16cc-31ac-478f-84a7-5cbb03baadba
The modules were disabled for some reason in r1172.
This just turns them back on for the real targets.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1237 ebee16cc-31ac-478f-84a7-5cbb03baadba
- syntax error in pios_board_posix.c introduced with Doxygen comment blocks
- platform dependant code had been added to openpilot.c instead of pios_board.c
- redundant header inclusion (stm32... already included by PiOS)
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1171 ebee16cc-31ac-478f-84a7-5cbb03baadba
- Added FlighSituation Module (development module for sensor fusion, mostly stub, possibly renamed later)
- Added Navigation Module (development module for navigating towards a point in space - DEVELOPMENT CODE, NOT STABLE YET (I am testing around with this))
- Changed Stabilization Module (uses local reference frame now. Stable except for code cleanup/review. Tested in simulator and outperforms old code.)
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1154 ebee16cc-31ac-478f-84a7-5cbb03baadba
The AHRS comms module now sync's with the AHRS and
exchanges interesting data periodically. Whenever
the link to the AHRS is down, the AHRSComms alarm is
raised.
This is fairly basic for now but provides the last
piece of the infrastructure to move data back/forth
between the OP and the AHRS.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1014 ebee16cc-31ac-478f-84a7-5cbb03baadba
PIOS SPI devices may now make use of automatic CRC generation
and checking on block transfers. Only supports CRC8 for now.
Since the SPI interface CRC calculation continues across message
boundaries (ie. not reset on every transfer), we must manually reset
the CRC registers for every transfer to allow the two sides of the
link to resynchronize.
Unfortunately, resetting the CRC registers requires disabling the
SPI peripheral which must now be done on every block transfer.
Note: The last byte of the tx buffer is never sent and is assumed to
be a place holder for the tx CRC8.
Note: The last byte of the rx buffer is expected to hold the rx CRC8.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1011 ebee16cc-31ac-478f-84a7-5cbb03baadba
The Attitude module will soon be handling updates for all UAVObjects
that require data from the AHRS. To reflect this expansion of scope,
it has been renamed to AHRSComms.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1009 ebee16cc-31ac-478f-84a7-5cbb03baadba
This object currently only holds the serial number of the attached
AHRS board. This will be retrieved each time communications are
(re)established with the AHRS board.
This will eventually be extended to hold some statistics for OP to
AHRS comms.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1008 ebee16cc-31ac-478f-84a7-5cbb03baadba
This object currently holds only the raw magnetometer readings and
an instantaneous heading calculation which are only really useful
for debugging. The contents of this object will change often as
development progresses.
Note: The magnetometer values are often garbage due to a problem
with i2c software on the AHRS.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1007 ebee16cc-31ac-478f-84a7-5cbb03baadba
The input data lines between the OP and AHRS boards had internal
pull-ups enabled. This seemed to be causing issues early on
during development of the inter-board comms. Not sure if this
is still necessary but this is how the current code was tested.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1006 ebee16cc-31ac-478f-84a7-5cbb03baadba
This defines the SPI message format as well as a few
initial messages for moving data across the link.
The v0 messages are place holders for firmware download
in the bootloader.
The v1 messages are to be used by the main application.
Note: This is not the final protocol definition.
Subject to change without notice.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1004 ebee16cc-31ac-478f-84a7-5cbb03baadba
Mark the device specific DMA IRQ handlers as strongly linked
aliases for the genericly named interrupt vector symbol.
Here's how this works...
* The address of the symbol DMA1_Channel2_IRQHandler is written
into the DMA1/Channel2 interrupt vector by the linker script.
* The startup_*.S file specifies Default_Handler() as a weakly
linked alias for DMA1_Channel2_IRQHandler.
* We now override the weakly linked alias with the strongly linked
PIOS_SPI_sdcard_irq_handler().
* This results in the address of PIOS_SPI_sdcard_irq_handler() being
written to the vector table for the DMA1/Channel2 interrupt.
* The PIOS_SPI_sdcard_irq_handler() function is now called whenever
the DMA1/Channel2 interrupt fires.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1003 ebee16cc-31ac-478f-84a7-5cbb03baadba
The AHRSComms alarm will be raised whenever the OP board
is not able to communicate with the AHRS board.
The navigation software on the OP board could use this
alarm to trigger its best attempt at an emergency landing.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1002 ebee16cc-31ac-478f-84a7-5cbb03baadba
The sequence number field for the attitude solution is
likely unnecessary. Removed.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1000 ebee16cc-31ac-478f-84a7-5cbb03baadba
Moving sounds folder to shared. Some sounds will be uploaded later.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@792 ebee16cc-31ac-478f-84a7-5cbb03baadba
- Created a pluggable COM layer
- Converted COM + USART init into static initializers
rather than typedefs
- Generalized the USB HID COM API to match the USART
API.
- Changed USART and COM layers to be data driven rather
than #ifdef'ing/switching on the specifics of each port
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@760 ebee16cc-31ac-478f-84a7-5cbb03baadba
Added support for SPI slave configurations to the pios SPI layer.
Converted the board specific configuration for the PIOS SPI layer to
use const static initializers rather than #defines (see pios_board.c).
SPI interface between the OP board and the AHRS is now operational at
a basic level, capable of moving simple single byte messages between
boards. Multi-byte, CRC protected messages will be added on top of this.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@759 ebee16cc-31ac-478f-84a7-5cbb03baadba
Split the floss-jtag.cfg file into separate versions
for OP and AHRS.
Push AHRS onto non-default ports for gdb, tcl and
telnet.
Update the AHRS gdb setup script to point at the new
gdb port.
Add (commented out) example sytax to support distinguishing
between multiple floss-jtag boards that don't have serial
numbers. Uses the usb bus address of each device as the
selector. See this patch posted to the openocd mailing list
for how to add this functionality to openocd:
http://lists.berlios.de/pipermail/openocd-development/2010-June/015785.html
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@755 ebee16cc-31ac-478f-84a7-5cbb03baadba
before
"**** Compiling C :" ../PiOS/STM32F10x/pios_sys.c "->" Build/pios_sys.o
after
**** Compiling C : ../PiOS/STM32F10x/pios_sys.c -> Build/pios_sys.o
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@731 ebee16cc-31ac-478f-84a7-5cbb03baadba
nmeaProcess was attempting to null-terminate the
NMEA sentence but was not considering that the
preceeding loop may have looped beyond the end
of the packet buffer.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@709 ebee16cc-31ac-478f-84a7-5cbb03baadba
Both EVents and ERrors were mistakenly being mapped to the
EVent IRQ channel.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@659 ebee16cc-31ac-478f-84a7-5cbb03baadba
This commit fixes all existing warnings.
All basic compiler warnings will now be treated as errors.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@658 ebee16cc-31ac-478f-84a7-5cbb03baadba
This fixes the COM interface over USB HID to the point where
it can establish and maintain solid communications with the UAVObject
Browser in the GCS.
Tested only on Linux. The USB HID interface is still disabled for now
until it is tested successfully by a wider group.
Edit telemetry.c and set ALLOW_HID_TELEMETRY to 1 to enable telemetry
over the USB HID interface and report your results in the forum.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@656 ebee16cc-31ac-478f-84a7-5cbb03baadba
- New Attitude module for AHRS (skeleton)
- New AttitudeSettings UAVobject
- New AttitudeActual UAVobject
- Regenerated UAVobjects
- Added new UAVobjects to OpenPilot and GCS builds
- New PiOS driver for OpenPilot AHRS (stubs only)
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@655 ebee16cc-31ac-478f-84a7-5cbb03baadba
NOTE: Delete any metaobjects that you may have saved in the SD card (delete all .obj files).
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@643 ebee16cc-31ac-478f-84a7-5cbb03baadba
This module reads from the BMP085 pressure sensor. It periodically
updates the pressure (kPa) and temperature (C) as well as the
calculated altitude (m).
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@640 ebee16cc-31ac-478f-84a7-5cbb03baadba
FreeRTOS has a strict requirement that even interrupt-safe API calls (ie.
those ending in "FromISR") can only be called from ISRs that are at lesser
or equal priorities to configMAX_SYSCALL_INTERRUPT_PRIORITY. See the
"configKERNEL_INTERRUPT_PRIORITY and configMAX_SYSCALL_INTERRUPT_PRIORITY"
section at:
http://www.freertos.org/a00110.html
The interrupt numbers used on the Cortex-M3 CPU has a somewhat backward
representation of the interrupt numbers so 255 = lowest priority and
0 = highest priority.
The calculation is further complicated by the STM32 implementation only using
the upper 4 bits of the priority value. Only 0x00, 0x10, 0x20, ..., 0xE0, 0xF0
represent useful interrupt priorities.
FreeRTOS requires that MAX_SYSCALL and KERNEL interrupt priorities are expressed
as raw unshifted 8-bit values to be programmed directly into the BASEPRI register.
The priority values passed to the NVIC initialization, however, are expected
to be 4-bit values and are shifted up by 4 within NVIC_Init() for you.
The end result is that we need this arrangement:
[highest priority]
NVIC_0 (Non-maskable-interrupt)
NVIC_1
NVIC_2
[Must NOT call FreeRTOS APIs above here]
configMAX_SYSCALL_INTERRUPT_PRIORITY (now at 48 = 0x30 = NVIC_3)
PIOS_IRQ_PRIO_HIGHEST (cur. NVIC_4)
PIOS_IRQ_PRIO_HIGH (cur. NVIC_5)
PIOS_IRQ_PRIO_MID (cur. NVIC_8)
PIOS_IRQ_PRIO_LOW (cur. NVIC_12)
configKERNEL_INTERRUPT_PRIORITY (240 = 0xF0 = NVIC_15)
[lowest priority]
The previous config had configMAX_SYSCALL_INTERRUPT_PRIORITY set at
191 (0xBF) which is effectively NVIC_11. This was allowing all of
the MID, HIGH and HIGHEST interrupt handlers to preempt the OS in
its critical sections. Since some of these ISRs were calling
FreeRTOS APIs, this would result in corrupting internal data structures
within the OS.
It should be ok to move the configKERNEL_INTERRUPT_PRIORITY to a higher
priority as long as it is less than configMAX_SYSCALL_INTERRUPT_PRIORITY.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@637 ebee16cc-31ac-478f-84a7-5cbb03baadba
Moved the generated python classes from the flight directory to the
ground directory since they are only used on the host, not the
embedded targets.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@628 ebee16cc-31ac-478f-84a7-5cbb03baadba
The uavobjectgenerator can now generate python classes for each
UAVObject definition. This is useful for writing simple test
applications in python that can exercise the UAVObject handling
code on the embedded boards.
This is a work in progress so the structure of the generated
classes is likely to change.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@623 ebee16cc-31ac-478f-84a7-5cbb03baadba
Commit @583 uncomments the HIDTest task creation. HIDTest task is configured to run at
priority 4 (== tskIDLE_PRIORITY + 4) which is higher priority than the "System" task at
priority 3 (== tskIDLE_PRIORITY + 3).
The HIDTest task never blocks so it prevents the system task (and any other task of priority
less than 4) from ever running.
This commit does not fix the root problem of HIDTest never blocking, but rather lowers
its priority to be equal to the system task so that they share the CPU. This is a
temporary workaround.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@586 ebee16cc-31ac-478f-84a7-5cbb03baadba
