- change/add a few printfs so they make more sense
- don't accidentally ignore command_acks
- don't forward commands to the same component id, and don't forward
commands that are broadcast to all components (target component 0)
This adds a class to allow for retransmission of outgoing commands.
The sent commands are kept in a timestamped list to check if they are
acked as required by the mavlink protocol.
If they are not acked within a timeout, they can be retransmitted.
Given the original poster's comment that "It happens very consistently for us." I suspect the motor spin observed in https://github.com/PX4/Firmware/issues/7457 is not caused by the original issue of slow decay on the PWM pins at reset, but the post reset pulse of 3.1 Ms arriving in a window that the ESC considers it valid.
The results from testing, indicated that the if the PWM pins were clamped low for > 300 Ms, prior to reset the motors did not spin. This would delay the the post reset pulse of 3.1 Ms out by > 300 Ms.
This change delays the reset and therefore the pulse by at least 400 Ms.
Note that Type buf_adc[i].am_data = int32_t, but everything else are floats. Suggest (float)(buf_adc[i].am_data), precisely as was done a few lines later for the voltage.
- one warn_rate_limited was missing
- vel_sp_slewrate was in the wrong order for smooth slowdown/speedup on takeoff and landing
- slow_land_gradual_velocity_limit was replaced by calls to math::gradual
- smooth takeoff speed got controllable by user input
- comments were corrected
- an additional check for the sanity of velocity setpoints was added
This requires support in the parsers, and thus the ULog file version is
increased.
As long as no data is appended, both, existing pyulog & FlightPlot, can
still read the new logs (they will output a warning).
The replay module will print an error, but still continue.