This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.

The mavlink shell is the only process creating a pipe.

This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.

The mavlink shell is the only process creating a pipe.

if there is not, the process on the other end of the pipe will just block.
This improves reliability over slow links.

There is no need to wait, and it would be the wrong way of doing
startup synchronization.

This makes sure the px4 process does not hang when Ctrl-C is pressed
during startup.

The initialization code is redundant and incomplete (only the first sensor
is done). I verified that all drivers already set this on startup.
For the mags, they all set their maximum supported update rate.
For the baro, the call can silently fail, as for example the MS5611 which
does not support 150Hz update. But it also sets the maximum in
initialization.

Tested on Pixhawk & pixracer.

In HIL mode we do not start the sensors anymore, so this is not needed.

Also it did not work (I did not try to find the reason, just noticed the
sensors kept publishing in HIL mode)

The param locking doesn't seem to be working on Snapdragon, so let's
just comment it out again.

This fixes the compass, see:
https://github.com/PX4/jMAVSim/pull/55

Resolves a conflict in the type of the index parameter in the dm_read and dm_write function signature, caused by a recent change in the dataman code.  This problem was causing the loading of the flight stack to fail on the aDSP.

On SITL startup we got a datalink lost failsafe message whenever home
was initialized. The reason that in standalone SITL, there is usually no
datalink connected. However, on ground, we shouldn't really failsafe,
therefore it makes sense not to enter the state in the first place.

Signed-off-by: zthorson <zachthorson@gmail.com>

Signed-off-by: zthorson <zachthorson@gmail.com>

The sensor_rest command added to the startup script for px4fmu_v4 hardware
was leaving the /dev/pwm_output0 driver open.  This would prevent the
pwm_out_sim module from registering as a simulated driver.  The result
would cause the system to properly boot in HIL mode, but you would not
be able to set any control surfaces.

Since sensor_rest and peripheral_reset are only used on initialization, the
drivers can be shut down after they have performed their reset functions.

Signed-off-by: zthorson <zachthorson@gmail.com>

logger will always log this topic, and a 0 timestamp will look worse in
FlightPlot. This will show a period of 0 attitude instead before ekf
is initialized.

The error counter is an indicator that the logger missed samples or dropped
due to a too small write buffer.

in preparation to the updated ekf2 replay

this is needed due to the additional topics logged with the logger

usage:
export replay_mode=ekf2
export replay=<abs_path_to_log.ulg>
make posix none