ROMFS/px4fmu_common/init.d/rc.io

#!/bin/sh
#
# PX4IO interface init script.
#

# If $OUTPUT_MODE indicated Hardware-int-the-loop simulation, px4io should not publish actuator_outputs,
# instead, pwm_out_sim will publish that uORB
if [ $OUTPUT_MODE = hil ]
then
    set HIL_ARG $OUTPUT_MODE
fi

if [ $IO_PRESENT = yes ]
then
	if px4io start $HIL_ARG
	then
		# Allow PX4IO to recover from midair restarts.
		px4io recovery
	else
		echo "PX4IO start failed"
		tune_control play -t 18 # PROG_PX4IO_ERR
	fi
fi
ROMFS: change shebang from #!zsh to #!/bin/sh This was required for shellsheck. 2018-12-18 09:26:22 +01:00			`#!/bin/sh`
Startup scripts major cleanup 2013-08-25 19:27:11 +02:00			`#`
Migrate px4io logic into rc.io. 2018-07-19 02:41:02 -06:00			`# PX4IO interface init script.`
Startup scripts major cleanup 2013-08-25 19:27:11 +02:00			`#`
px4io: When running HITL, don't publish actuator_outputs. Fixes #13471. When running in HITL mode, pwm_out_sim publishes actuator_outputs. px4io unconditionally publishes the uOrb actuator_outputs. When HITL is configured, the px4io copy of the uOrb has all zeros. The result is that there are two publications, one valid, and one all-zeros. This causes the HIL_ACTUATOR_CONTROLS mavlink message to be incorrect (all-zeros) and the SERVO_OUTPUTS_RAW mavlink message to be inconsistent, as it takes the data from one or the other uOrb randomly each cycle. The fix is to let px4io know that HITL is in effect when it is started, and modify px4io to suppress publication in this case. This is a bigger more complicated fix than I would like, but I think it is conceptually correct. Signed-off-by: Nik Langrind <langrind@gmail.com> 2019-11-15 20:01:40 -05:00
			`# If $OUTPUT_MODE indicated Hardware-int-the-loop simulation, px4io should not publish actuator_outputs,`
			`# instead, pwm_out_sim will publish that uORB`
			`if [ $OUTPUT_MODE = hil ]`
			`then`
			`set HIL_ARG $OUTPUT_MODE`
			`fi`

rcS: fixes for SYS_USE_IO=0 rc.io is called from 2 places in rc.interface: - if [ $OUTPUT_MODE = io -o $OUTPUT_MODE = uavcan_esc ]: - 'set OUTPUT_MODE io' is only set within USE_IO=yes, so removing the check in rc.io has no effect. - in case of UAVCAN, we also want the IO for RC, now covered in the next case. - Further down ('Start IO for RC input if needed.'). This is intended to start IO for RC only, when fmu is already started. However the previous check '$USE_IO = yes' in rc.io prevented that. In addition we don't start rc_input in case of $USE_IO = no. Fixes no RC on Pixhawk 2 with SYS_USE_IO=0. 2020-03-26 13:53:24 +01:00			`if [ $IO_PRESENT = yes ]`
ROMFS: Be less verbose on boot 2015-04-25 09:01:22 +02:00			`then`
px4io: When running HITL, don't publish actuator_outputs. Fixes #13471. When running in HITL mode, pwm_out_sim publishes actuator_outputs. px4io unconditionally publishes the uOrb actuator_outputs. When HITL is configured, the px4io copy of the uOrb has all zeros. The result is that there are two publications, one valid, and one all-zeros. This causes the HIL_ACTUATOR_CONTROLS mavlink message to be incorrect (all-zeros) and the SERVO_OUTPUTS_RAW mavlink message to be inconsistent, as it takes the data from one or the other uOrb randomly each cycle. The fix is to let px4io know that HITL is in effect when it is started, and modify px4io to suppress publication in this case. This is a bigger more complicated fix than I would like, but I think it is conceptually correct. Signed-off-by: Nik Langrind <langrind@gmail.com> 2019-11-15 20:01:40 -05:00			`if px4io start $HIL_ARG`
rc.io:Add USE_IO == yes && IO_PRESENT == yes test On a FMU without a px4io (FMUv4, NXPhlite etc), this code should not be run. 2018-08-10 12:54:18 -07:00			`then`
			`# Allow PX4IO to recover from midair restarts.`
			`px4io recovery`
			`else`
ROMFS: startup remove bootlog.txt 2020-11-11 14:20:55 -05:00			`echo "PX4IO start failed"`
drivers/tone_alarm and tune_control small improvements/cleanup - drivers/tone_alarm: move to ModuleBase and purge CDev (/dev/tone_alarm0) - drivers/tone_alarm: only run on tune_control publication (or scheduled note) rather than continuously - drivers/tone_alarm: use HRT to schedule tone stop (prevents potential disruption) - msg/tune_control: add tune_id numbering - systemcmds/tune_control: add "error" special case tune_id - move all tune_control publication to new uORB::PublicationQueued<> - start tone_alarm immediately after board defaults are loaded to fix potential startup issues - for SITL (or other boards with no TONE output) print common messages (startup, error, etc) 2020-10-05 21:39:26 -04:00			`tune_control play -t 18 # PROG_PX4IO_ERR`
rc.io:Add USE_IO == yes && IO_PRESENT == yes test On a FMU without a px4io (FMUv4, NXPhlite etc), this code should not be run. 2018-08-10 12:54:18 -07:00			`fi`
ROMFS: Be less verbose on boot 2015-04-25 09:01:22 +02:00			`fi`