Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect reading of Notifystate bitmask in canbus monitor #36

Open
steffensol opened this issue Jun 20, 2023 · 2 comments
Open

Incorrect reading of Notifystate bitmask in canbus monitor #36

steffensol opened this issue Jun 20, 2023 · 2 comments

Comments

@steffensol
Copy link

Hi all,

I've been working on a system that needs to read the incoming Notifystate from the autopilot, and during my testing, I found out that the bitmask is misread by the GUI tool.

First, lets have a look at this bitmask as defined in the dronecan standard;
image

I had a test autopilot lying on the bench and armed it in acro mode (which doesn't require any GPS, position estimate etc.). Powered through a power brick with current + volt sensing. The current / voltage limits were not outside of the min_voltage parameters set up in the autopilot as seen in the screenshot below.

My understanding is that the VehicleState message bitmask of 26 should have represented "PREARM + PREARM_GPS + ARMED" - however the tool seems to indicate Flying, failsafe_batt and gps_glitch. As this is in acro mode, there is no need for GPS, and the voltage was within acceptable limits, and should not have flagged failsafe_batt. As I managed to arm the autopilot, the prearm must have been OK, and since i was in acro mode - no requirement for GPS exists, and therefore PREARM_GPS is also OK.

image

Unfortunately, my coding skills are not up to the level of debugging where this GUI tool depends on other libraries, and this error could be caused by incorrect code in those libraries.

If someone would like to have a look at this, it could greatly benefit others.
Thanks

@steffensol
Copy link
Author

As an update, this seems to be related to the way the bits are being summed up in the bitmask....

The value 26 seems to be read as:

uint8 VEHICLE_STATE_INITIALISING = 0
uint8 VEHICLE_STATE_ARMED = 1
uint8 VEHICLE_STATE_FLYING = 2
uint8 VEHICLE_STATE_PREARM = 3
uint8 VEHICLE_STATE_PREARM_GPS = 4
uint8 VEHICLE_STATE_SAVE_TRIM = 5
uint8 VEHICLE_STATE_ESC_CALIBRATION = 6
uint8 VEHICLE_STATE_FAILSAFE_RADIO = 7
uint8 VEHICLE_STATE_FAILSAFE_BATT = 8
uint8 VEHICLE_STATE_FAILSAFE_GCS = 9
uint8 VEHICLE_STATE_CHUTE_RELEASED = 10
uint8 VEHICLE_STATE_EKF_BAD = 11
uint8 VEHICLE_STATE_FW_UPDATE = 12
uint8 VEHICLE_STATE_MAGCAL_RUN = 13
uint8 VEHICLE_STATE_LEAK_DET = 14
uint8 VEHICLE_STATE_GPS_FUSION = 15
uint8 VEHICLE_STATE_GPS_GLITCH = 16
uint8 VEHICLE_STATE_POS_ABS_AVAIL = 17
uint8 VEHICLE_STATE_LOST = 18
uint8 VEHICLE_STATE_THROW_READY = 19
uint8 VEHICLE_STATE_POWERING_OFF = 20
uint8 VEHICLE_STATE_VIDEO_RECORDING = 21

So it calculates integers 2+8+16 = 26

but in the autopilot this is actually a bitmask, so the true value of a message of Flying + Failsafe_batt + GPS_Glitch would have been bits 2, 8 and 16 high or 65796 as an integer.

@tridge
Copy link
Member

tridge commented Mar 21, 2024

@steffensol it looks right to me with current ArduPilot master:
image

163856 is 0x28010, so 3 bits set, that is just how bitmasks work

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants