The param is not really required anymore with the actuator
configuration. Also, when it is set to 0, RC doesn't work for some
boards which would be nice to avoid.
Signed-off-by: Julian Oes <julian@oes.ch>
This fixes the case where the hardware detection fails on CubeBlack when
a CAN device is connected to CAN1 and talking, and therefore preventing
the check from getting a clear result.
Signed-off-by: Julian Oes <julian@oes.ch>
This consolidates the version/revision detection function.
This should allow for actual changes in a follow up commit.
Signed-off-by: Julian Oes <julian@oes.ch>
- 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>
This removes the odd px4_i2c_bus_external override which was confusing
me and lead to odd and inconsistent results.
The function is now only available with an int as the argument.
- 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)
internal PX4IO safety_off state is removed and replaced with a normal safety button event. From this 'commit' commander is taking care of the PX4IO safety.
- on common IMUs like the mpu6000, mpu9250, icm20602, etc each FIFO
sample is only 12 bytes so this is still more than large enough for the
worst case transfer
- free memory is getting tight on these older boards (depending on
configuratoin) and the pixhawk 2 cube still has 2 other superior IMUs, so this is just
dropping dead weight
internal PX4IO safety_off state is removed and replaced with a normal safety button event. From this 'commit' commander is taking care of the PX4IO safety.
- most px4_io-v2 boards have a blue LED that breathes for status
- the pixhawk 2.1 (hex) re-used this blue LED for as an IMU heater (active low), but kept the same board id (so we have to detect at runtime)
- the new cubepilot boards (yellow, orange) inverted the polarity of this heater pin
- untangle the mess slightly so that things we know statically (eg cubepilot cubeorange LEDs and heater polarity) are handled at build time.
- previously an invalid decode would continue to be transferred to the FMU (at 50 Hz) and published to the rest of the system as successfully decoded new RC data
- by only publishing new successful decodes we can more effectively discard invalid data in downstream consumers
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.