This is the new interface to control external LED's (user-facing).
Features:
- Supports maximum N Leds (where the board can define N)
- on/off/blink M times
- Different priorities
- Allows setting a single led or multiple at once
- use uorb queue to not drop any info, only do 2 tasks per cycle
- also print a warning on low stack (which will be added to ulog)
this allows to gather statistics of each task's stack usage over time.
MavLink spec implementation
implemented vehicle_roi topic
rename old gimbal to rc_gimbal
little changes
corrected RC Gimbal group
Starting ROI implementation in commander
implementation done, needs to be tested
uhm..
add todo
Change to float32 for x,y and z
remove mission topic again, not needed
change roi coordinates to lat, lon and alt
adjust to float64
starting mount implementation
correcting small mistakes, compiles now
add todos
further progress
implementing parameters
adjust default parameters
started implementation of mavlink
fix typo
change to lat, lon and alt
fix typo :D
change to double (to represent float64)
add global_position_
add mount topic
commander mount implementation done
cleanup
almost finished
little fix
codestyle fixes
leave pitch at 0 degrees
added pitch calculation
codestyle changes
Undo vehicle_mount, react to updated parameters, parsing of CMD_DO_MOUNT_* in mount.cpp
start implementing mode override
forgot a semikolon.
add debug
Finish implementation of mount override and manual control.
fix codestyle
correct cleanup
rename to vmount
works now
fix rebase error
fix polling
refactoring and custom airframe for gimbal
couple changes
remove warnx
almost done
finally
What is going on?
change back to actuator_controls_2
working
bump parameter version number and some clarification
fix submodules
- ulog file message rate limited to 50Hz
- queuing with size 2
- this replaces the mavlink log message in the ulog
(but the mavlink warnings & errors still go to the ulog)
Drawbacks of the previous method: when writing to the SD card, there are
high delays in the write() call of several 100ms, every now and then. The
frequency and length of these events depend on:
- SD card
- used logger bandwidth
- bandwidth of gps data (RTCM)
Since the whole gps thread was blocked during this period, it lead to
gps timeouts and lost module.
What we do now is: publish an orb topic with queuing. This makes it async
and the logger takes care of buffering. This means it's best to:
- use high logger rate
- use large logger buffer
- reduce logger bandwith by disabling unused topics
Daniel Agar
Mohammed Kabir
Paul Riseborough
Beat Küng
Kabir Mohammed
Simone Guscetti
mazahner
Andreas Antener
Julian Oes
Leon