- the last check expects pre_arm to run so we need to enable the
preflight checks. This is closer to the real system.
- as a result we need to enable HIL for other tests so that the sensors
are not checked.
This allows to bypass preflight and prearm checks.
During development there are regular cases where I just want to arm the
board/vehicle no matter what, and the preflight checks are guaranteed to
fail (e.g. sensors uncalibrated, inconsistent, powered via USB, etc.).
Allowing an easy and quick way to arm (assuming you know what you are
doing) helps to speed up development considerably and is less frustrating.
Reason: if you don't want preflight checks, you don't want prearm checks
either (these are the circuit breakers, like usb connected check).
The other changes are cleanup and rework of operations.
In most cases, arming_state_transition is called with fRunPreArmChecks set
to true, so no change in behavior.
The cases with fRunPreArmChecks=false are:
- unit tests
- in_arming_grace_period=true (quick arming after disarm)
- VEHICLE_CMD_PREFLIGHT_CALIBRATION (does not transition to armed)
When we send a command to any sysid or any compid, we need to match an
ack from a specific sysid or compid. If we don't do that, we keep
sending retransmissions and eventually time out.
The int32 param COM_ARM_AUTH is mapped to a packed struct. However, this
struct was not actually packed (anymore) and therefore the values were
applied incorrectly.
I fixed this by applying the packed attribute. By using a union with a
int32_t I could rid of the warning about address-of-packed-member.
Mavlink does not correctly forward messages that have the target_system or target_component routing fields in the message.
Some investigation revealed that the Mavlink::forward_message function is incorrectly utilizing the mavlink_msg_entry_t.target_system_ofs and mavlink_msg_entry_t.target_component_ofs fields. These offsets are intended to be used relative to the start of the message payload. But, as implemented, these offsets are incorrectly being used relative to the start of the message. This pull-request corrects that problem.
I also correctly made use of the mavlink_msg_entry_t.flags field to determine if a message contains a target_system or target component field. The previous check incorrectly assumed that they would always be non-zero if present.
Signed-off-by: Mark Owen <maowen801@gmail.com>
The file writer thread could get into a state where it blocked infinitely
on pthread_cond_wait() (or rather until the logging stops).
This is very rare and the following conditions must be met:
- the buffer is almost empty (<4KB filled), so that the writer thread does
not write anything.
- an fsync call is scheduled (happens once every second)
- the fsync call takes a long time (several 100ms), during which time the
complete log buffer fills up.
The main thread would then get into dropout state where it does not call
_writer.notify() anymore.
Notifying the writer thread on every loop update of the main thread fixes
that.
It does not increase resource usage.
