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
Generic ESC harmonic notch handling #16725
Conversation
Maybe replace HAVE_AP_BLHELI_SUPPORT with HAVE_ESC_TELEM_SUPPORT in some places? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice stuff, loving it!
9c448f2
to
0172f74
Compare
Implements a part of #16645 together with amilcarlucas#4 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AP_PiccoloCAN and AP_KDECAN support are missing in this PR
This is working on my 3" quad with BLHeli bi-dir dshot |
881fe26
to
83b0d47
Compare
Ok, PiccoloCAN, UAVCAN and KDECAN done. Will need some testing and I am not convinced about the motors API - might need to use masks instead |
2853df4
to
65e9b45
Compare
Tridge and I have zero'ed in on a slightly different design ... |
I think the
What do you think? |
The alternate design we came up with was to have an additional callback - update_esc_telemetry() that populated the frontend with the additional telemetry data together with a timestamp. Then callers only need to call the front end - no need for virtual functions at all in the main. This will also cope with multiple drivers populating the ESC data. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, we are getting there :)
fc3ee8d
to
d6f657a
Compare
This adds less than 90 lines of code, and reduces FW size by about 1300 bytes (ArduCopter on Durandal) 👍 |
I do think that it needs a semaphore to ensure the consistency of the telemetry data. |
@amilcarlucas - I've deliberately not done that because I don't want timing critical code (e.g. bi-dir dshot) being required to take out the lock. If we really want a lock then I'll do a backend/frontend copy like we do for the IMUs. But at the moment I don't think its necessary. All the data types are 32bits or less (i.e. atomic) and the only coordinated update is between the timestamp and data type. We only really care about the timestamp for out of data data - at which point nothing is being written anyway so a little out of date is fine. So at the moment I don't think anything bad will happen as its stands and it avoids some contention. |
remove send_esc_telemetry_mavlink() log telemetry data in frontend record volts, amps and consumption as floats
…ing with other ESCs remove send_esc_telemetry_mavlink() log telemetry data in frontend remove datastructures and semaphore obsoleted by AP_ESC_Telem* (<amilcar.lucas@iav.de>) record volts, amps and consumption as floats
remove send_esc_telemetry_mavlink() remove datastructures and semaphore obsoleted by AP_ESC_Telem* (<amilcar.lucas@iav.de>) record volts, amps and consumption as floats
… with other ESCs log ESC telemetry data in frontend
…ng with other ESCs refactor to capture and output slewed rpm values enable with HAL_WITH_ESC_TELEM move notch calculation to front end refactor telemetry data into frontend cope with blended data add mavlink send function log telemetry data in frontend add SITL ESC telemetry record volts, amps and consumption as floats report telemetry transmission errors disable ESC Telemetry inclusion when there is no need for it move ESC_Telem logging to the AP_ESC_Telem class (by amilcar.lucas@iav.de) various cleanups (by amilcar.lucas@iav.de) add support for raw ESC rpm check RPM validity for mavlink output Use const when applicable
rename AP_BattMonitor_BLHeliESC -> AP_BattMonitor_ESC record volts, amps and consumption as floats Correct ESC-telemetry-based voltage and temperature (<amilcar.lucas@iav.de>) Correct ESC-telemetry-based voltage and temperature when less than 12 ESCs are used (<amilcar.lucas@iav.de>) fix jumps in consumed current (<amilcar.lucas@iav.de>) Implement temperature readings (<amilcar.lucas@iav.de>) Fix temperature scaling (<amilcar.lucas@iav.de>)
Squashed and rebased |
added Ampere hours unit in LOG_ESC_MSG log ESC volts, amps and consumption as floats update ESC log file structures consumption in mAh Correct the current_tot unit, motor_temp unit and error_rate unit in comments (<amilcar.lucas@iav.de>) move ESC_Telem logging to the AP_ESC_Telem class (<amilcar.lucas@iav.de>) correct log structure (<amilcar.lucas@iav.de>)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That seems ok. I will do another pass for review later
I've re-tested ToshibaCAN ESCs and they also seem to work. So from a basic functionality point of view I think KDECAN and ToshibaCAN telemetry continues to work. |
i have UAVCAN ESCs to test |
all working well on a quad with 4 UAVCAN ESCs |
This is a generic abstraction for ESC telemety which I have ported all of the existing telemetry providers to.
It incorporates dynamic notch support, rpm slew, mavlink and logging support. Overall the code has got smaller.
There is also a new autotest for the dynamic notch support.