There is some race condition where in rare cases the topic publication
right after creating the writer did not get received on the ROS side.
This happens even with reliable QoS & reliable transport.
We need to open the device later in the work queue and not in the
constructor during task_spawn.
There is already a lazy open in place, so just removing this fixes the
problem for me.
This adds RTL_TYPE 4 which means continue the mission or reverse back to
the takeoff location, whichever is closer in terms of mission items
in-between.
This would be nicer to have on a distance rather than mission item count
basis but that would require access to the dataman and make it more
complex.
* don't constrain airspeed for scaling to maximum airspeed
Signed-off-by: RomanBapst <bapstroman@gmail.com>
* fix max function
Signed-off-by: RomanBapst <bapstroman@gmail.com>
* remove hardcoded max
Signed-off-by: RomanBapst <bapstroman@gmail.com>
---------
Signed-off-by: RomanBapst <bapstroman@gmail.com>
Signed-off-by: Silvan <silvan@auterion.com>
boards: increase max mission items for boards with >=1kb RAM to 1000
Signed-off-by: Silvan <silvan@auterion.com>
boards: increase NUM_MISSION_ITMES_SUPPORTED for SITL to 10000
Signed-off-by: Silvan <silvan@auterion.com>
Since we have SYS_DM_BACKEND, the user has to option on all boards
to store the mission on the RAM, thus thus define got obsolete.
Signed-off-by: Silvan <silvan@auterion.com>
vtol_type: timeout transition earlier if we use airspeed and airspeed has
not increased above blend airspeed after openloop front transition time.
Signed-off-by: RomanBapst <bapstroman@gmail.com>
---------
Signed-off-by: RomanBapst <bapstroman@gmail.com>
* Bidirectional DShot
Co-authored-by: Julian Oes <julian@oes.ch>
* f4/f1 support, not supported
* fix f1 build target
* sanity check timer_channel value, fix CCxNP ifdef, debug stuff
* removed debug code, added define for H7 HAVE_GTIM_CCXNP
* round robin sampling for less than 4 DMA
* unlimited esc_status logging
* dshot: fix formatting
* dshot: add define for number of DMA channels to use
This allows individual boards to override the number of DShot channels
and hence avoid round robin capture of the RPM feedback.
* ARK: enable 4 DMA channels for DShot on 6X
* dshot: publish when all channels are updated
This slows down the ESC_STATUS publication in the case of round robin
capture. E.g. for 800 Hz output with one DMA channel, the ESC_STATUS is
now published at 200 Hz.
* dshot: avoid duplicate publications for bidir and telem
Instead of publishing both bidirectional dshot updates as well as
telemetry updates, we now combine the data from both streams, and
publish whenever we get RPM updates, as the latter arrives with higher
rate, e.g. 200 Hz with round robin, or faster otherwise.
When combining the data, we take RPM from bidirectional dshot, and the
rest from telemetry.
When we have only one of the two, either telemetry or bidirectional
dshot, we just publish that one.
* boards: add ark fpv and pi6x BOARD_DMA_NUM_DSHOT_CHANNELS
* dshot: turn off debug build
---------
Co-authored-by: Julian Oes <julian@oes.ch>
Co-authored-by: alexklimaj <alex@arkelectron.com>
There is already another check for battery_unhealthy, so a separate state
and ID are required.
Fixes the error:
ERROR [failsafe] BUG: duplicate check for caller_id 74
