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

Added function to query SYS_STATUS present/enabled/health flags #2383

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

dakejahl
Copy link
Contributor

Added function to query SYS_STATUS present/enabled/health. This allows applications to look at specific sensor statuses, such as logloader which looks at the MAV_SYS_STATUS_LOGGING flag

@dakejahl
Copy link
Contributor Author

Not sure what the check for diff check is doing or why it's failing

@JonasVautherin
Copy link
Collaborator

Thanks!

I guess the question is whether it should expose an uint32_t or some list of booleans for all (or a subset) of the sensors in MAV_SYS_STATUS_SENSOR.

Does it always make sense to expose all those values, or are some values fundamentally "internal"? I could imagine for instance that if SENSOR_BATTERY=false means "there is no battery", maybe it should go together with the battery update (e.g. an is_present field in https://github.com/mavlink/MAVSDK-Proto/blob/main/protos/telemetry/telemetry.proto#L566-L573?). Same for the GPS, maybe if a GPS sensor is not "present", we should have a FixType saying "NO_GPS_SENSOR" (if there is a difference between "no GPS connected" and "no GPS present").

What do you think?

Not sure what the check for diff check is doing or why it's failing

I think it would be the style check. Try running ./tools/fix_style.sh 👍

@dakejahl
Copy link
Contributor Author

I did run fix_style.sh, it's only failing on 24.04 🤔

Does it always make sense to expose all those values, or are some values fundamentally "internal"?

I thought about this but decided to expose them all since PX4 currently doesn't implement all of them but could at any point in the future. It would just be a pain to have to updated mavsdk again if for example I decided to add the flags for a VIO system, or optical flow, or precision landing. So I figured just expose the raw 3 flags and we get everything in one go.

@julianoes
Copy link
Collaborator

I usually don't want to expose bitflags like this but make the API clearer. I know that's a pain but otherwise we might as well expose all over MAVLink directly and we're back to square one.

So generally the idea is to have boolean flags that actually mean something instead and can be queried.

For logloader specifically, could you use passthrough instead?

@julianoes
Copy link
Collaborator

I did run fix_style.sh, it's only failing on 24.04 🤔

You need to fix the style on 24.04 or use the docker helper.

@dakejahl
Copy link
Contributor Author

I could use passthrough but then my code becomes disorderly. Okay if I changed it to a boolean flag for each of those mentioned sensors, what pattern should I follow?

This isn't doing anything more

tools/run-docker-clang-format.sh tools/fix_style.sh .

@dakejahl
Copy link
Contributor Author

dakejahl commented Aug 23, 2024

if there is a difference between "no GPS connected" and "no GPS present"

also part of why I was avoiding the specific flags.. PX4 makes it hard to use the sys_status_sensor flags directly since they're coupled to the HealthAndArmingChecks Report. I can't remember exact details, but when I implemented the loggerCheck I wasn't able to set the present/enabled flags directly, and as a result they toggle true/false together. I think the expectation would be that present means the vehicle has logging functionality (sd card) and enabled would mean it's actively logging.

Copy link

@JonasVautherin
Copy link
Collaborator

JonasVautherin commented Aug 23, 2024

Okay if I changed it to a boolean flag for each of those mentioned sensors, what pattern should I follow?

I would think something like the winch status flags? https://github.com/mavlink/MAVSDK-Proto/blob/517fef5a3a673e9b50f65a56dff350c6af515564/protos/winch/winch.proto#L77-L101:

/*
 * Winch Status Flags.
 *
 * The status flags are defined in mavlink
 * https://mavlink.io/en/messages/common.html#MAV_WINCH_STATUS_FLAG.
 *
 * Multiple status fields can be set simultaneously. Mavlink does
 * not specify which states are mutually exclusive.
 */
message StatusFlags {
    bool healthy = 1;           // Winch is healthy
    bool fully_retracted = 2;   // Winch line is fully retracted
    bool moving = 3;            // Winch motor is moving
    bool clutch_engaged = 4;    // Winch clutch is engaged allowing motor to move freely
    bool locked = 5;            // Winch is locked by locking mechanism
    bool dropping = 6;          // Winch is gravity dropping payload
    bool arresting = 7;         // Winch is arresting payload descent
    bool ground_sense = 8;      // Winch is using torque measurements to sense the ground
    bool retracting = 9;        // Winch is returning to the fully retracted position
    bool redeliver = 10;        // Winch is redelivering the payload. This is a failover state if the line tension goes above a threshold during RETRACTING.
    bool abandon_line = 11;     // Winch is abandoning the line and possibly payload. Winch unspools the entire calculated line length. This is a failover state from REDELIVER if the number of attempts exceeds a threshold.
    bool locking = 12;          // Winch is engaging the locking mechanism
    bool load_line = 13;        // Winch is spooling on line
    bool load_payload = 14;     // Winch is loading a payload
}

@julianoes
Copy link
Collaborator

julianoes commented Aug 25, 2024

I think it will either be a Status struct per component:

message StatusFlags {
   bool present = 1;
   bool enabled = 2;
   bool healthy = 3;
}

Or a flat enum:

enum Status {
    STATUS_NA = 0; // Not present, not enabled, not healthy
    STATUS_PRESENT = 1; // Not enabled, not healthy
    STATUS_ENABLED = 2; // Not present, not healthy
    STATUS_PRESENT_ENABLED = 3; // Not healthy
    // STATUS_HEALTHY = 4; // -> invalid
    STATUS_PRESENT_HEALTHY = 5; // Not enabled 
    // STATUS_ENABLED_HEALTHY = 6; -> invalid
    STATUS_PRESENT_ENABLED_HEALTHY = 7; -> All ok!
}

@JonasVautherin
Copy link
Collaborator

I think it will either be a Status struct per component:

The StatusFlags struct with 3 booleans is a lot more intuitive to me, I would say 🙈

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

Successfully merging this pull request may close these issues.

3 participants