This repository has been archived by the owner on Oct 1, 2021. It is now read-only.
forked from PX4/PX4-Autopilot
-
Notifications
You must be signed in to change notification settings - Fork 441
PX4IO: Added support for JR XBus Mode B #36
Open
omcaree
wants to merge
125
commits into
ArduPilot:master
Choose a base branch
from
omcaree:XBusInput
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If we check OUTPUTS_ARMED then we can't update trim values and scaling in flight, as there is no way to clear OUTPUTS_ARMED. If safety is on then it should be perfectly safe to update the mixer and RC config or reboot for fw update
airspeed sensors often need to be on longer cables due to having to be outside the prop wash.
the vehicle may not have setup a control_mode. We need to check the return of orb_copy() to ensure we are getting initialised values
This merges in the PX4Flow changes from upstream
we were running out of file descriptors with the new battery monitoring
Add mpu6000 regdump command for debugging mpu6000.
this will catch both bad SPI bus comms and a sensor that has been reset causing incorrect configuration.
this uses the same method as is now used in the MPU6000 to check that the sensor retains its correct values
this mirrors the ardupilot driver. We have seen situations where the mpu6000 on the Pixhawk comes up in SLEEP mode, despite a reset
this checks at runtime that key registers have correct values
this follows the factory calibration self-test method in the datasheet to see if the sensor still has the same calibration it had in the factory
used to generate a error case for reset testing
this prevents the mpu6000 getting in a really weird state!
this may help automatic reset on the faulty boards
this seems to prevent a mpu6000 reset from causing an issue on the l3gd20H
added "hmc5883 tempon" and "hmc5883 tempoff" to enable/disable
if we can't read the temperature registers 10 times then disable the feature.
this also fixes the behaviour of the -C option
…or is fixed to the autopilot assembly.
Also use full charge capacity instead of design capacity so that an old battery's capacity will appear as lower than its original capacity but it will still report 100% charged after charging
this runs the sampling of the accelerometer 200usec faster than requested and then throw away duplicates using the accelerometer status register data ready bit. This avoids aliasing due to drift in the stm32 clock compared to the lsm303d clock
this runs the mpu6000 200usec faster than requested then detects and disccards duplicates by comparing accel values. This avoids a nasty aliasing issue due to clock drift between the stm32 and mpu6000
JR XBus Mode B uses the same serial port parameters as the DSM port (3.3V logic, 115200, 8n1), this update adds support for decoding it. XBus Mode B is effectively the SRXL protocol, using the Multiplex 12-channel format (start charachter 0xA1) Decoding of XBus packets only occurs if a valid checksum is received, so this should not interfere with DSM packets. - RC Failsafe is now disabled when XBus data is bein received
Because DSM packets do not have checksums it is possible for the DSM decoder to find 'valid' packets in XBus data, decode them, and override XBus outputs. To avoid this behaviour, an option has been added to choose (currently at compile time) which input decoding to use. Ideally, this option should be runtime selectable
Conflicts: src/modules/mavlink/mavlink_messages.cpp src/modules/px4iofirmware/controls.c src/modules/px4iofirmware/px4io.h src/modules/px4iofirmware/xbus.c
dam_input was always returning false as we weren't seeing a full DSM frame, this was unfortunate for XBus decoding! Fixed this by only checking for a full DSM frame in the DSM decoding block
Conflicts: src/modules/px4iofirmware/px4io.h
it would be great if that were merged, would be a great improvement! |
I would appreciate this one being merged too. |
It would be great if that were merged. |
hey, can somebody say exactly, was it implemented or not? |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
JR XBus Mode B uses the same serial port parameters as the DSM port (3.3V logic, 115200, 8n1), this update adds support for decoding it.
XBus Mode B is effectively the SRXL protocol, using the Multiplex 12-channel format (start charachter 0xA1)
Decoding of XBus packets only occurs if a valid checksum is received, so this should not interfere with DSM packets.