what they would be on a real board. Also fixed a typo in stabilization.c which made me lose time when trying to understand the code...
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2260 ebee16cc-31ac-478f-84a7-5cbb03baadba
sometimes thrown, and made errors not lock it up by default. It works for me,
but since this has historically been associated with lots of lock ups please
check your systems carefully.
PiOS/I2C: Make the bus by default try to recover from errors instead of locking
up
PiOS/I2C: After a bus error and clocking all previous data create a STOP
condition to make sure bus is released (note, this also requires creating a
START condition first)
PiOS/I2C: If the same event hits the I2C bus twice in a row then disregard
second one, there is no situation where we should get the same event multiple
times that matters and this gets us out really quickly to catch the real
events. I was seeing this with repeated 0x70084 which means byte transmitted.
This is related to STM32 bugs in the IRQ timings I believe.
PiOS/I2C: 1) Mask out some bits we don't care about in the event flags
2) Don't lock up if the give semaphore fails, although why it does is strange
3) Recover from bus failure through the "auto" state path instead of just
coding state
PiOS/I2C: Change the reset bus code to follow
http://www.analog.com/static/imported-files/application_notes/54305147357414AN686_0.pdf
(thanks for the reference Neontangerine). Although this may actually NOT clear
the bus the first time through, subsequent bus errors should eventually clock
it out. The up side is it is less likely to clock a bunch of 1s into an ESC
and make it run up.
PiOS/I2C: Some cleaned up code for getting a snippet of the history when
something strange happens
PiOS/I2C: Export logging information from I2C through a UAV object
PiOS/I2C: Improve the diagnostic information
PiOS/I2C: Need to handle the event 0x30084. This seems to happen between a
byte transmitted and new byte started
PiOS/I2C: Handle the NACK condition by simply going to the stopping state.
PiOS/I2C: Add a new NACK state to handle sending the STOP signal after a NACK
following the STM documentation. Other error conditions still are not dealt
with.
PiOS/I2C: Should handle the NACK condition from all the write cases. Need to
think about read cases
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2239 ebee16cc-31ac-478f-84a7-5cbb03baadba
BEWARE: I have not flown my quad with this code, so please be careful, test, and report!
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2234 ebee16cc-31ac-478f-84a7-5cbb03baadba
than the ekf runs and also be more tolerant of timing jitter
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2191 ebee16cc-31ac-478f-84a7-5cbb03baadba
ManualControlSettings so that planes can disable the timeout
feature for gliding (holding roll on a plane not so good).
Note: This will require you to reconfigure your ManualControlSettings
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2185 ebee16cc-31ac-478f-84a7-5cbb03baadba
will automatically disarm after 30 seconds without motor. This behavior will
need to be parameterized for planes which might idle for a while.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2181 ebee16cc-31ac-478f-84a7-5cbb03baadba
before cleared at the end of each loop - including one after an alarm
Flight/Actuator: Similar change to make sure not having updates from
stabilization (i.e. no AHRS) doesn't trigger a watchdog reset
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2140 ebee16cc-31ac-478f-84a7-5cbb03baadba
lost. Warning though: it takes ~5-10 seconds for the flight telemetry status
to go from connected so this solution still isn't great.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2070 ebee16cc-31ac-478f-84a7-5cbb03baadba
end characters occur while sentence coming in instead of reprocessing whole
sentence for each character
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2041 ebee16cc-31ac-478f-84a7-5cbb03baadba
causes it to trigger most of the time every 1 ms which is consuming tons of
CPU. Also lower the failsafe timeout since its likely due to overloading the
event system and we don't want to delay 100 ms.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2005 ebee16cc-31ac-478f-84a7-5cbb03baadba
IRC, but suggestions are welcome. In the long run we probably need a sensible
way of embedding some information in the LED but it's not obvious to me. Also
could have done with callback - sue me. ;)
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1997 ebee16cc-31ac-478f-84a7-5cbb03baadba
simple - outdated - won't compile
Experimental - outdated - won't compile
les - development version - not stable
les+corvus - development version - not stable
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1993 ebee16cc-31ac-478f-84a7-5cbb03baadba
Before, moving your throttle trim slightly could cause ManualControl to think the receiver was not connected
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1885 ebee16cc-31ac-478f-84a7-5cbb03baadba
so it can also change parameters of Stabilization. Please check your aircraft
behavior with this patch, but default behavior should be unchanged.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1878 ebee16cc-31ac-478f-84a7-5cbb03baadba
exceed CPU requirements of PID. Also add add lesstabilization UAVObject to Makefile
to fix compile errors.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1870 ebee16cc-31ac-478f-84a7-5cbb03baadba
