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

AP_Periph: add support for extended ESC DroneCAN message. #27772

Merged
merged 6 commits into from
Aug 19, 2024

Conversation

IamPete1
Copy link
Member

@IamPete1 IamPete1 commented Aug 7, 2024

This builds on #27771 to allow testing of both it and #27755.

They do work:
image

On Periph this is not enabled by default. If it is enabled it sends each ESC in turn such that they are each sent at the set ESC_EXT_TLM_RATE, by default this is 10 times lower than the default ESC status message rate.

I had to add getters into AP_ESC_Telem for periph to read the values. I also added some token values to the SITL esc backend.

I have also added a helper to ESC telem for the get functions to check the type bitmask and if the data is stale in one call.

@IamPete1 IamPete1 marked this pull request as ready for review August 7, 2024 10:24
Tools/AP_Periph/can.cpp Outdated Show resolved Hide resolved
Tools/AP_Periph/can.cpp Outdated Show resolved Hide resolved
@tridge
Copy link
Contributor

tridge commented Aug 13, 2024

I think we can remove the volatiles, then merge on CI pass

@IamPete1
Copy link
Member Author

I think we can remove the volatiles, then merge on CI pass

I have done some more reading, i think its correct here. It enforces that it must be called on a object which is marked volatile. So because the objects are declared volatile here:

const volatile AP_ESC_Telem_Backend::TelemetryData& telemdata = _telem_data[esc_index];

The volatile on the method enforces that, so it should be a compiler error if you were to try calling it on a none volatile instance of the object.

@IamPete1 IamPete1 requested a review from tpwrules August 13, 2024 00:56
@IamPete1 IamPete1 force-pushed the periph_extended_esc branch 2 times, most recently from 90e4067 to b95fc49 Compare August 13, 2024 01:56
Copy link
Contributor

@tpwrules tpwrules left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Found a bug and a few opportunities for cleanup, but once fixed I think this is ready to go in. The data looks good in the DroneCAN GUI tool in SITL (after the fix).

uint32_t last_esc_telem_update_ms;
void esc_telem_update();
uint32_t esc_telem_update_period_ms;
#if AP_EXTENDED_ESC_TELEM_ENABLED
void esc_telem_extended_update(const uint32_t &now_ms);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this a reference? It isn't written in the function.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess it really comes out the same in this case, but passing the reference is often less data than passing the object.

Copy link
Contributor

@tpwrules tpwrules Aug 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not using the reference will save a bit of flash though.

Comment on lines +1720 to +1723
uint8_t power_rating_pct;
if (esc_telem.get_power_percentage(i, power_rating_pct)) {
pkt.power_rating_pct = power_rating_pct;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could avoid the temporary, the data type should be compatible.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, but then you need the whole IGNORE_RETURN thing for the bool. I think this is clearer.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That should only apply if the function is marked to warn if the return is ignored, which it doesn't seem to be. I think it is clearer to just call the function, perhaps with a comment that all packet fields have been inited to 0. The DSDL does not specify what the "unavailable" value is for this field (though we were sending 0 before).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It really should be marked to warn..... but I didn't want to get into that in this PR.

Tools/AP_Periph/can.cpp Show resolved Hide resolved
Tools/AP_Periph/can.cpp Outdated Show resolved Hide resolved
Copy link
Contributor

@tpwrules tpwrules left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good now, tested it with the DroneCAN GUI tool and SITL.

Decided that the volatile was probably necessary due to potential cross-thread access, and that the check for an out of range ESC number needed to be moved to avoid UB.

@tridge tridge merged commit d0d5dfd into ArduPilot:master Aug 19, 2024
93 checks passed
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.

4 participants