- split up old module into two, one handling setpoint generation, one control
- add lateral and longitudinal control setpoints topics that can also be
injected from companion computer
- add configuration topics that (optionally) configure the controller
with limits and momentary settings
Signed-off-by: RomanBapst <bapstroman@gmail.com>
* usb: Added parameter to enable always starting mavlink on USB.
Refactored cdcacm_init into a module and added a paramter to allow always starting mavlink on
USB, also added a paramter to choose the mode. The current default behavior is to wait and listen
for data on USB and auto-detect the protocol (mavlink, nsh, ublox). This results in the mavlink
stream not starting until something else on the mavlink network sends a packet first. The new
default behavior is to always start mavlink.
Added parameters
MAV_USB_ENABLE -- default 1 (always start mavlink on USB)
MAV_USE_MODE -- default 3 (onboard)
* added 3 retries for opening serial port in mavlink, removed sleep before sercon
* added DRIVERS_CDCACM_AUTOSTART to ark-v6x default.px4board
* added CONFIG_DRIVERS_CDCACM_AUTOSTART=y to default.px4board for boards with CONFIG_CDCACM in their nsh/defconfig
* format
* remove PGA460 from COMMON_DISTANCE_SENSOR to save flash
* remove LIS2MDL from COMMON_MAGNETOMETER to save flash
* disable CONFIG_DRIVERS_CDCACM_AUTOSTART for fmu-v5 protected.px4board
* moved and renamed parameters, removed mode logic in mavlink
* changed parameter names, added mode none
* remove parameters from mavlink
- during casual testing on default configs the stack was penetration was reaching ~90% which is a bit too close for comfort
- increasing by 50% to be conservative
* Fixedwing rate control into a separate module
* Start fw_rate_control for vtol
* Move over airspeed related parameters to fw_rate_control
Co-authored-by: Silvan Fuhrer <silvan@auterion.com>
Co-authored-by: Peter van der Perk <peter.vanderperk@nxp.com>
Co-authored-by: David Sidrane <David.Sidrane@NscDg.com>
Co-authored-by: alexklimaj <alex@arkelectron.com>
- new modules/simulation directory to collect all simulators and related modules
- new Tools/simulation directory to collect and organize scattered simulation submodules, scripts, etc
- simulation module renamed to simulator_mavlink
- sih renamed to simulator_sih (not a great name, but I wanted to be clear it was a simulator)
- ignition_simulator renamed to simulator_ignition_bridge
- large sitl_target.cmake split by simulation option and in some cases pushed to appropriate modules
- sitl targets broken down to what's actually available (eg jmavsim only has 1 model and 1 world)
- new Gazebo consistently referred to as Ignition for now (probably the least confusing thing until we fully drop Gazebo classic support someday)
This enables flow control on CDCACM for the NuttX boards which fixes a
problem where HITL would stall.
The stall could happen if the hardware would be a bit too slow in
keeping up with the incoming messages. Often, this happened on arming
because the logger would take some time to log all parameters right at
the beginning.
The stall would then not recover due to NuttX bug where the rx interrupt
would not be restored correctly and instead only a slower watchdog would
release the next read. This watchdog takes 200ms which means it's hard
to impossible to get out of the situation without restarting sim and/or
PX4. For more information about the issue, see:
apache/incubator-nuttx#3633
As a workaround, until that bug is fixed, and because it makes sense
anyway, I propose to enable FLOWCONTROL for the serial via USB.
- cmake NuttX build wrapper compile in place instead of copying source tree to build directory
- slightly faster skipping necessary copying (depending on system)
- allows debugging in place
- easier to work directly in NuttX following official documentation
- simplifies overall build which should make it easier to resolve any remaining NuttX dependency issues in the build system
- the downside is switching back and forth between different builds always require rebuilding NuttX, but I think this is worth the improved developer experience
- also no longer builds px4io and bootloader in every single build, for most users these rarely change and we're wasting a lot of build time
