When we use a gimbal connected via "RC", so PWM via the Aux channels, we
need to set the gimbal_device_id to 1 as per the protocol.
This was missing for GIMBAL_DEVICE_ATTITUDE_STATUS, so I added that, and
fixed the name of that variable while at it.
* listener: only clear screen with multiple messages
* listener: fully clear before printing again
Otherwise, we end up seeing artifacts from the previous print.
This updates the GPS submodule which includes NMEA/Unicore fixes:
- Add correct return value for sat infos
- Only publish on position updates
- Request required topics at 5 Hz for Unicore
I suggest to clear the screen when using the listener with -n.
This way the updates don't just scroll by which isn't legible but
instead stay in place and update, similar to the top command.
It looks like the BMP280 was heavily filtered, leading to a step
response of around 3 seconds. Comparing it to baro logs of BMP388 and
MS5611, it looks very slow.
I therefore suggest to disable the on device IIR filter which makes the
log data look more like the other baros.
This fixes an issue where we dropped acks that we should have sent out
just because the queue was clogged with acks that have nothing to do
with us and just happen to be sent to us. We should just ignore them and
not publish them to uORB.
We should not send out acks for commands that are not targetted at us.
This can confuse other MAVLink components and MAVLink commands just
don't scale that way, and it unnecessarily fills up our ack queue.
This was likely introduced to debug when MAVLink components were
implemented incorrectly sending commands to a wrong target.
The most we should do in this case is to print/log an info.
A gimbal user needs to be able to receive gimbal device messages such as
GIMBAL_DEVICE_INFORMATION. Therefore, we need to forward this MAVLink
instance.
* boards: change board ID of KakuteH7 mini
Holybro would like to consolidate the board ID to what is used in
ArduPilot.
* boards: update KakuteH7mini bootloader
This is due to the board ID change.
When the px_uploader.py is used scripted, so without an interactive
shell, the progress bar doesn't update. Therefore, I suggest to print a
new line instead of a carriage return for the non-interactive shell
case.
The bootloader can often get stuck parsing random MAVLink traffic,
thinking it had seen a GET_SYNC.
Therefore, this commits adds a two step check which requires a GET_SYNC
followed by a GET_DEVICE to make sure it's really an uploader script
talking to it, and not just random data.
This fixes the SITL tests that fail in CI because we catch NAN as non
zero after cast to int. To fix this I've added the check whether they
are finite at all.
The checks for param5 and param6 would be a bit trickier because they
can be int or float, so I have omitted them for now.
Now that ubuntu-latest has been pushed to Ubuntu 24.04, we need to fix
up the pip install.
While at it, we might as well pin to the ubuntu 24.04 version, so we
don't have this happen to use out of the blue again.
It looks like vertical velocity as well as velocity accuracy are not
available using NMEA, so we extract all velocities from the Unicore
ACRICA message instead.
I could not extract the open_drone_id helpers to a separate lib because
it would require the mavlink headers while the mavlink library would
also depend on it, so it ended up being a circular dependency.
Instead, I'm now just using the headers from within the mavlink module
as well as from the uavcan driver.
This will send the System message if it is already being sent by a ground
station. Otherwise, it will assemble the message itself using the
takeoff/home location.
This extracts the function mapping from MAV_TYPE to MAV_ODID_UA_TYPE to
the library, so that it can be re-used later by the remote ID
implementation over DroneCAN.
Signed-off-by: Julian Oes <julian@oes.ch>
This resets the USARTs' clock source selection to the default, in case
it has been changed by the bootloader.
This is required if booting from the ArduPilot bootloader which happens
to reset the clock selection to PLL.
Without this fix, UARTs (including the console) is garbled, so
presumably at an invalid baudrate.
* ist8310: do reset before WHOAMI call
Apparently, the IST8310's WHOAMI register is writeable. Presumably, this
can get corrupted by bus noise. It is only reset if powered off for 30s.
Therefore, we do a reset before doing the WHOAMI.
* ist8310: improve comment
Co-authored-by: Beat Küng <beat-kueng@gmx.net>
---------
Co-authored-by: Beat Küng <beat-kueng@gmx.net>
This fixes various edge cases when input is set to both: RC and
MAVLink gimbal protocol v2.
Specifically:
- We no longer immediately reset primary control if there is no update,
otherwise this will reset immediately after an commands.
- Talking of commands: GIMBAL_MANAGER_CONFIGURE no longer switches
control to MAVLink but only an actual incoming setpoint command does.
- And incoming setpoint command only triggers UpdatedActiveOnce which
means we will check RC again afterwards and if there is big movement
switch back to RC. That's the intuitive thing to do until we have
better reporting about who/what is in control.
- Also, with RC we no longer always set us to be in control but only on
major movement.
Includes:
- Remove some of the outdated Python2 checks and compatibility.
- Try not catch all exceptions but only the expected ones. Otherwise,
this makes it really hard to debug if anything unexpected actually
goes wrong.
- Make use of fstrings.
- Make output slightly prettier.
Signed-off-by: Julian Oes <julian@oes.ch>
This adds a new protocol extension which allows to get the bootloader
version.
The bootloader version is different from the bootloader protocol
revision which has stabilized at 5 and is not easy to update unless a
bootloader is actually breaking the protocol. The reason being that both
the Python script as well as the uploader used in QGC will not attempt
to load firmware if they don't know the bootloader version, so it could
basically be considered a "breaking" protocol revision.
Signed-off-by: Julian Oes <julian@oes.ch>
If the STM32H7 fails to program or erase a full chunk of 256 bytes, the
ECC check will trigger a busfault when trying to read from it.
To speed up erasing and optimize wear, we read before erasing to check
if it actually needs erasing. That's when a busfault happens and the
erase time outs.
The workaround is to add an option to do a full erase without check.
Credit goes to:
https://github.com/ArduPilot/ardupilot/pull/22090
And the protocol option added to the bootloader is the same as for
ArduPilot, so compatible.
Signed-off-by: Julian Oes <julian@oes.ch>
This notes the reference yaw angle for the Septentrio Mosaic-H.
It's unfortunately a bit tricky in that Unicore has the main antenna
in front by default while Septentrio decided to put the aux antenna in
front.
Signed-off-by: Julian Oes <julian@oes.ch>
For Septententrino we seem to sometimes fill the buffer pretty full.
If we ask for too much, readAtLeast will fail completely and make the
GPS discovery logic fall over. Therefore, let's not ask for too much and
just read what we can given the available buffer.
Signed-off-by: Julian Oes <julian@oes.ch>
When flow control is used together with DMA, we need to add a pulldown
to CTS. Without it, it assumes flow control and gets stuck when
CTS is not connected.
Signed-off-by: Julian Oes <julian@oes.ch>
The IMU topic is not zeroed, and the clipping information was not
copied, so this field ended up being garbage.
Signed-off-by: Julian Oes <julian@oes.ch>
This adds the ICM42686p as a possible alternative to the existing IMUs.
Apparently, the ICM20689 was never actually used in these boards.
Signed-off-by: Julian Oes <julian@oes.ch>
This switches all SENS_EN_INAXXX params to 0 by default and instead uses
the i2c_launcher command.
However, if any one the SENS_EN_INAXXX param is set, it no longer tries
to auto-configure it.
Signed-off-by: Julian Oes <julian@oes.ch>
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 switches from the horribly intertwined ringbuffer implementation to
the new VariableLengthRingbuffer implementation.
By ditching the previous implementation, we fix MAVLink message
forwarding, which didn't work reliably. The reason it didn't work is
that multiple mavlink messages could be added but only one of them was
sent out because the buffer didn't keep track of the messages properly
and only read the first one.
Signed-off-by: Julian Oes <julian@oes.ch>
This adds a reusable class for a FIFO ringbuffer that accepts variable
length packets. It is using the Ringbuffer class internally.
Signed-off-by: Julian Oes <julian@oes.ch>
From looking at the history the BMM150 rotation was initially 0. Then,
this was changed to 6 when the intent was to only change it for Skynode.
A bit later, the rotation was changed back to 0, but only for Skynode.
This tells me that rotation 0 was correct for all 6X including Skynode
all along.
Signed-off-by: Julian Oes <julian@oes.ch>
This updates the gps/devices submodule which includes a fix that
requests the Unicore HEADINGA message in case the message is not enabled
by default.
Signed-off-by: Julian Oes <julian@oes.ch>
If the measured voltage is more than 65v we need to split the voltage
over multiple cells in order to avoid overflowing the uint16. This is
according to the MAVLink spec.
Signed-off-by: Julian Oes <julian@oes.ch>
The extension fields need to be 0 by default according to the MAVLink
spec. This is because extensions are 0 by default and need to be 0 when
unknown/unused for backwards compatibility.
The patch also simplifies the flow slightly in that it doesn't create a
temporary array but just fills in the cell voltages directly.
Signed-off-by: Julian Oes <julian@oes.ch>
This is required to process data from the ADS1115 ADC and enables the
params BATx_I_CHANNEL and BATx_V_CHANNEL.
Testing is required whether this actually works on Pixhawk 6X though.
Signed-off-by: Julian Oes <julian@oes.ch>
This adds support for the TI LP5562 RGB LED driver.
Things to note:
- The driver is initialized in simple PWM mode using its internal clock,
for R,G,B, but not for W(hite).
- The chip doesn't have a WHO_AM_I or DEVICE_ID register to check.
Instead we read the W_CURRENT register that we're generally not using
and therefore doesn't get changed.
- The current is left at the default 17.5 mA but could be changed using
the command line argument.
Datasheet:
https://www.ti.com/lit/ds/symlink/lp5562.pdf
Signed-off-by: Julian Oes <julian@oes.ch>
This is now using the advanced lift drag plugin.
The important step was to enable airmode for yaw, otherwise yaw gets
saturated at low throttle and we can barely roll.
The other trick was to raise airspeed a little bit to avoid operating
too much at the lower end of throttle where control authority is low.
Signed-off-by: Julian Oes <julian@oes.ch>
The API is cleaner if the control_data is const reference and the device
compid is an explicit output argument.
Signed-off-by: Julian Oes <julian@oes.ch>
When flow control is used together with DMA, we need to add a pulldown
to CTS. Without it, it assumes flow control and gets stuck when
CTS is not connected.
Signed-off-by: Julian Oes <julian@oes.ch>
When we fall back to another link, we are already doing a uORB copy when
checking the data. Therefore, we should further down use/send that data
instead of overwriting it immediately.
Signed-off-by: Julian Oes <julian@oes.ch>
I don't think it makes sense to slow down switching RTCM injection to
once every 5 seconds. If we don't have corrections, we should check and
use whatever we get as soon as possible.
Signed-off-by: Julian Oes <julian@oes.ch>
We need to reset the instance after looping through all instances.
Otherwise, we are left with the last instance if none is valid but have
not updated the _selected_rtcm_instance which is what is logged.
Therefore, this change fixes the logged RTCM instance.
Signed-off-by: Julian Oes <julian@oes.ch>
It turns out that I had omitted implementing the gimbal_device_id which
is the component ID of the gimbal device that the gimbal manager (in
this case PX4) is responsible for.
Signed-off-by: Julian Oes <julian@oes.ch>
This adds the ability to manually set who has primary control over a
gimbal and also adds printing it as part of the status.
This is helpful, especially while working on the QGC gimbal v2
implementation.
Signed-off-by: Julian Oes <julian@oes.ch>
Julian Oes