Led(LED1 different color on each board) Sequence:
1-Power On
2-Led ON for 3 seconds (you can disconnect during this time - safety measure)
3-Led flashes very quickly while the board is being programed (because the program is stored in memory this is very fast and looks like a led glitch)
4-If all good - LED flashes 3 times with a 1sec period and turns off - you may now reboot.
4-If an error ocurred - LED will keep flashing with a 500ms period until power off
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2804 ebee16cc-31ac-478f-84a7-5cbb03baadba
Move channel StabilizationSettings from ManualControlCommand to
AttitudeDesired, unify channel normalization and put them all into ManualControl
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2797 ebee16cc-31ac-478f-84a7-5cbb03baadba
- Removed all unnecessary device instances and their cfg's.
- SPI to SD card
- I2C
- Aux USART
- Moved SPI baudrate setting into cfg rather than init func.
- Abstracted forcing slave select under OPAHRS API.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2786 ebee16cc-31ac-478f-84a7-5cbb03baadba
The COM layer now uses 32bit device ids rather than
8bit. All code that stores these ids must now use
uint32_t to hold them.
Since these 32bit numbers are really just opaque
pointers, it is (reasonably) safe to assume that
they won't be 0. The logic around tracking the
*_previous_com_port could probably be cleaned up
to remove that assumption.
Missed this fixup in the recent hwinit changes.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2776 ebee16cc-31ac-478f-84a7-5cbb03baadba
data. I don't like this but because of the way the calibration routine works
(sets all gains to 1) this makes the values so far out or range the EKF doesn't
get to run and the mag wasn't previously being updated.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2765 ebee16cc-31ac-478f-84a7-5cbb03baadba
order to free a timer. Mode PIOS_DELAY (not working cleanly) to TIM3 because
Spektrum resets TIM2 count.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2758 ebee16cc-31ac-478f-84a7-5cbb03baadba
that it will completely follow the accel attitude each cycle and is way too
high. Ki=1 means the gyro bias wil be correct by accels each cycle (way too
high).
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2755 ebee16cc-31ac-478f-84a7-5cbb03baadba
convergence of gyro bias, then the normal values can be lower.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2753 ebee16cc-31ac-478f-84a7-5cbb03baadba
because this is what is determines when the Stabilization code executes.
Because we aren't oversampling gyros relative to the PID in CC we should set
the attitude first (computational time to do so is negligible).
Also change update rate to 500 Hz.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2750 ebee16cc-31ac-478f-84a7-5cbb03baadba
Not yet used anywhere but will eventually allow
debug pins to be assigned during runtime init based
on configuration found in a new uavobject.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2741 ebee16cc-31ac-478f-84a7-5cbb03baadba
This makes it easier to step through the module init
sequence in gdb.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2740 ebee16cc-31ac-478f-84a7-5cbb03baadba
per target as defined in Makefile (and/or Make include file) For
OpenPilot this is flight/OpenPilot/UAVObjects.inc For sim_posix and
sim_win32 needs rebuild of uavobjectgenerator and uavobjects!
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2736 ebee16cc-31ac-478f-84a7-5cbb03baadba
also increase the telem queue to decrease event errors (can be reverted later if
we need the memory back)
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2730 ebee16cc-31ac-478f-84a7-5cbb03baadba
