-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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
Add support for HobbyWing ESC telemetry #22649
base: master
Are you sure you want to change the base?
Conversation
libraries/AP_ESC_Telem/AP_ESC_Telem_HobbyWing_Platinum_PRO_v3.cpp
Outdated
Show resolved
Hide resolved
dce9289
to
8ae0860
Compare
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.
I agree this should not go in the IO thread - too slow.
The configuration needs some thought.
Some stuff should go in the frontend if possible to reduce flash and memory usage.
|
||
void AP_ESC_Telem_HobbyWing::init() | ||
{ | ||
for (uint8_t i=0; i<32 && num_escs<ARRAY_SIZE(escs); i++) { |
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.
Shouldn't this be dependent on whether you have support for 32 motors?
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.
Probably :-) But the parameter is always going to be 32-bits regardless of your support for 32-bit, sooo...
// @Bitmask: 0:Channel1,1:Channel2,2:Channel3,3:Channel4,4:Channel5,5:Channel6,6:Channel7,7:Channel8,8:Channel9,9:Channel10,10:Channel11,11:Channel12,12:Channel13,13:Channel14,14:Channel15,15:Channel16, 16:Channel 17, 17: Channel 18, 18: Channel 19, 19: Channel 20, 20: Channel 21, 21: Channel 22, 22: Channel 23, 23: Channel 24, 24: Channel 25, 25: Channel 26, 26: Channel 27, 27: Channel 28, 28: Channel 29, 29: Channel 30, 30: Channel 31, 31: Channel 32 | ||
// @User: Advanced | ||
// @RebootRequired: True | ||
AP_GROUPINFO("V3_MASK", 2, AP_ESC_Telem_HobbyWing, channel_mask_v3, 0), |
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.
Urg, I see what you mean about the parameters. What I was thinking was that we should create a "motor custom configuration" class a bit like Pete's "custom rotation". The custom configuration would have a mask, a pole number and an output type. You could then limit the number of configurations you allow. This would avoid some of the explosion of parameters and make it easier to have mixed types.
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.
I was thinking of adding an enable parameter at the top of this parameter thingy.
I'm a bit worried your proposed solution will need to a cross-product problem.
One option we discussed at SV today was having basic configurations selectable via enumeration values and requiring scripting to configure anything more signficant.
Note that the current situation only allows you to select poles-per-backend-type, so something like the Arace Griffin would need some scripting assistance.
Also note that we kind of expect most people to use a Periph to turn these crappy serial protocols into less-crappy DroneCAN messages, so this configuration won't be applicable to most users. Notable exception being Heli users who I think like using HobbyWing ESCs and they're pretty frugal with their motor counts so don't really need a Periph.
|
||
// start a thread to handle the reading from all of those UARTs: | ||
if (!hal.scheduler->thread_create( | ||
FUNCTOR_BIND_MEMBER(&AP_ESC_Telem_HobbyWing::thread_main, void), |
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.
I think this should be at the same priority as BLHeli - whatever that is
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.
Sounds right. Perhaps this should share a thread with blheli?
AP_Int32 channel_mask_x4; | ||
AP_Int8 motor_poles_x4; | ||
|
||
static const uint8_t MAX_ESCS { 8 }; |
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.
Max 8?
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.
Yeah, that was a little arbitrary :-)
static const uint8_t MAX_ESCS { 8 }; | ||
|
||
AP_HobbyWing_ESC *escs[MAX_ESCS]; | ||
uint8_t servo_channel[MAX_ESCS]; |
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.
These should be stored in the front-end surely - you are blowing up the amount of data required.
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.
This is the frontend? We only create one of AP_ESC_Telem_HobbyWing_Telem
, in the same way we only have one of the blheli manager thingy created in SRV_Channels.cpp
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.
@andyp1per perhaps you were suggesting we could do without AP_ESC_Telemetry_HobbyWing
entirely and put these all of the members into AP_ESC_Telemetry
? I could definitely do that, but I would need to change the way the update_telemetry call gets triggered. I emulated the way we've previously done things, by hooking the stuff in SRV_Channels
- but I reckon there's a good argument to be made for putting the list-of-ESCs directly into AP_ESC_Telemetry
. Not sure how we'd handle the parameters at that point; hanging stuff off SERVO_
is already pretty weird.
(p.s. I dislike AP_ESC_Telemetry_SITL - it keeps on overwriting my perfectly-good HobbyWing telemetry :-/ )
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.
IDK, I prefer not to break encapsulation - but there are also a number of parameters that we are duplicating everywhere. It would be good to at least have a consistent mechanism for that data. If its consistent and common then it could live in the front end
Closes #10460 |
3d48e18
to
6d04a82
Compare
Temperature support fattened things up:
|
6074945
to
063eb0e
Compare
How does this relate to the PR @khancyr is about to do? |
it integrate my stuff in it as Peter have more bandwidth to finish it and integrate this into the same Lib ! |
063eb0e
to
9b2947f
Compare
@andyp1per per our discussions - I've restructured to use little configuration objects for the motor groups. They're actually much more like @rmackay9 's "EKF source set" things than @IamPete1 's compass stuff. I've also eliminated that middle-class as I was threatening to do. |
f669d36
to
7bf28f2
Compare
eb1afaa
to
96a9265
Compare
I've force-pushed this. I'll look at this again in September. |
@peterbarker do you have the hardware to test this on? |
@amilcarlucas @peterbarker I have the hardware to test this on (HobbyWing Datalink v2) and I'd be more than happy to contribute it his. Please let me know if I can help in any way... |
96a9265
to
794a9ae
Compare
I have some of it, but not the datalink devices |
I'll make sure this branch builds - if I can ship you a binary to test that would be good (better if you can build it yourself, of course :-) ) Hopefully October I can put more time into this... |
60aa4ce
to
d97681f
Compare
@peterbarker I'm surely available to test! Unfortunately I wouldn't be able myself to build the software myself, so it would be far more productive to receive as "plug and play" software as possible 🙏🏻 |
Now that datalink support has been added in lua to master, I guess some of this PR can be removed. Would be nice to use the datalink simulator to test the lua script, is that even possible? |
I would prefer to still have this . Lua isn't suited for everything |
Hi @peterbarker I've merged and compiled the code from your pr, but am still having trouble retrieving rpm data from the escs. I've set up the CAN nodes as in this tutorial (https://discuss.ardupilot.org/t/using-matekl431-adapters-for-pwm-and-dshot/85781?page=2) and am using the Hobbywing Xrotor 80A. I have uavcan.equipment.esc.RawCommand in the CAN bus monitor, but not the status packets. I was hoping for some advice on what the issue could be - should the code be working with this esc, and have I just made a mistake somewhere? Or is it just that this particular esc is not yet supported? Any help would be appreciated :) |
not much to test for this driver - we only use RPM
d97681f
to
608e2ec
Compare
just built this for orange cube plus and I'm still not getting current back on the telem. any ideas? |
Hi @peterbarker , I'm running a Hobbywing Platinum 40A V4 ESC and have been trying to get its telemetry on a Pixhawk 6C. Tried to compile your branch which was able to do successfully, but after flashing to the autopilot, it looks like it does not initialise properly as communication is lost immediately after going into Initialise flight mode. Any idea on how I can get this running? Would really like to get the telemetry reading from a single HobbyWing ESC. |
This PR now parses both v3 and v4 protocols.
edit: added support for the XRotor-v4
edit: added support for DataLink devices
Something like this: https://www.dragonrc.com.au/HW-100A-V3-Platinum-series-aircraft-system-p/drc-hw100av3.htm
Reads telemetry data from this ESC and makes it available via ESC telemetry.
Includes simulator for same.
There are some things that we need to discuss:
AP_ESC_Telemetry::Protocol::HobbyWingPlatinumProv3
,AP_ESC_Telemetry::Protocol::TMotor
etc