Servers by jDrones

CAN / UAVCAN ESCs


(ACPUK) #1

CAN / UAVCAN ESCs.
I know there is several topics on the CAN ESCs. I thought is best to have a fresh DEV topic on CAN ESCs and the development ‘wants’ and ability of them.
I appreciate there is much work going on with CAN dev:- https://gitter.im/ArduPilot/CANBUS
I did not want to butt in to the discussion so I am posing here.
From my perspective as a commercial UAV operator CAN ESCs are a must next step. The question is what we do with them…… rather the data they can feed back.
Some benefits are clear like potential neater wiring and auto detect motor layout ect.
The main thing is data from the ESC
RPM
Temp (external motor temp would be good)
AMPS
From this we can derive motor and ESC health which from a commercial operator is paramount for safety.
Question is what to do with the data? Looking at a multirotor:-
We can detect a motor is failing,
Inform pilot via Mavlink ‘YES Please’
Can Ardupilot take evasive action, difficult one, it really depends on rig build i.e. can the rig sustain a failed motor? If so an RTL is initiated, if not then at least a LAND. My personal feeling is all commercially used rigs must be capable of at least one motor fail and sustained flight.
If Ardupilot knows there is a motor / ESC fail it can have a heads up to allow it to try and fly the rig home.
Shut motor down is a clear one, to prevent overload and fire.
What are the criteria of a fail? How do we decide a motor is failing? APMs VS expected RPM / requested rpm perhaps. This probably would require some sort of calibration i.e. motor and prop performance test during setup but this would not really reflect real flight characteristics. Can this be detected purely from expected RPM and actual RPM?
NOTE the Freelfy Alta FAIL! The ESCs were too sensitive to prop disturbance, shutting the motor down causing crashes…
LOG:- is there head room for logging 8x motor data sets? If not perhaps this could be an option if we have a PH2.1 with the Edison (or some other CC setup) and it can to the logging.

We are fortunate enough to be in the position to take on some development staff soon. I would be more than happy to assign one of the developer’s time and some funding towards developing and testing a new ESC. I note there are some issues with the ESC V1.6 but is this a baseline we can use as a start.
Ardupilot is assumed and I want to do my bit to support the development and I think this is where I can help.


(David Buzz) #2

there is a lot of execlent open-source work going on in the ESC area eg: ( software / hardware )
https://github.com/PX4/sapog / https://docs.zubax.com/sapog
https://github.com/vedderb/bldc / http://vedder.se/2015/01/vesc-open-source-esc/
https://github.com/jschall/esc / ( hardware not released for this yet )
( I’m sure I’ve missed some, others pls add links to software/hardware combos if u know them …)


(David Buzz) #3

also some of these products aren’t available, etc but the links ,u might find useful:
http://www.auav.co/product-p/pixhawkesc16dev.htm
http://www.auav.co/product-p/esc-30.htm

and here is some other interesting links:
https://github.com/PX4/Hardware/tree/master/sapog_reference_hardware
https://pixhawk.org/modules/pixhawk_esc
https://zubax.com/product/zubax-orel-20


(David Buzz) #4

http://ardupilot.org/copter/docs/common-uavcan-escs.html


(ACPUK) #5

Thanks David, Lots of good links. Question is, is there to be a protocol standard? The Dev team can’t accommodate all possibilities whilst developing the HAL.
Also as mentioned, what are we going to do with the data, how are we going to use this feedback to implement safety and recovery of the aircraft. A LOT to develop and test.


(Rob_Lefebvre) #6

What are the details on the Freefly Alta problem? First I’ve heard of it.

Very complicated topic.

One idea, is that since a multirotor is usually constructed of multiples of identical ESC/motor/propeller sets, that the ESC’s can inter-communicate status. One failure detection method, would be to look for one motor/prop set to be running outside of the throttle/rpm curve established by the other sets.

Though, even this has to be approached with caution. And this is true also if one is trying to “calibrate” the motor/prop sets on the ground.

The Throttle/RPM relationship is not static. It’s at least 3-dimensional. With the 3rd dimension being the propeller’s inflow velocity.

If you do a static ground test, you end up with a throttle/rpm curve, but it’s only for the static condition, where the propellers inflow velocity is purely self-induced. (ie: the propeller inflow is caused by the propeller itself).

However, in real, dynamic flight (ie: not a hover in zero wind), that changes a lot. Propeller inflow velocity will vary due to climb rate, lateral speed, etc. etc. And even this will not be constant for all motor/prop sets on a given vehicle in a given flight condition. In high speed lateral flight, the rear motors will experience a significantly different inflow velocity compared to the rear motors.

This isn’t an easy topic. The answer to every question about rotary aerodynamics is “it depends”.


(proficnc) #7

Hi,
I’ve been working on the CAN ESCs from day one. I built the first hardware that Pavel then used to make this work, and every hardware since has been a derivative of some sort.

We (ProfiCNC) are doing high power Can ESCs at the moment. Not much public info yet, but feel free to contact me privately.

The current design is a single CAN, 8s ESC, and the prototypes are flying nicely.

The first production run will be for the Solo, as it’s an easy testbed.

Version 2, will be much more advanced, with a much better ground up design. 60v capable, redundant CAN, sensors and sensorless, with many other still secret features.

keen to hear your thoughts on this


(ACPUK) #8

Hi Rob,
Very well put.
Ref the Alta, we lost a few of them due to their ‘smart’ ESCs. They attempted to ‘manage’ the ESC to detect an anomaly within the propulsion system. Trouble is it was too sensitive. During a fast exploration the motor become loaded beyond the firmware’s expectation causing the ESC to shut down the motor. This would load up the other motor and so on… causing the rig to lose multiple propulsion causing a nasty crash. They did a recall a while back. Learn from this….

Hi Proficnc,
I have to say first off THANK YOU for the Pixhawk 2.1, well done.
I will PM you.


(ACPUK) #9

If frame_type=Octa coaxial
If frame can sustain flight on top 4 motors or bottom 4 motors.
We could have 2 or 3 PID sets.
Set 1 all 8 motors
Set 2 top 4 motors
Set 3 bottom 4 motors (if needed)
If bottom motor fails disable all bottom motors and use PID set 2 ETC…


(ACPUK) #10

sub pre-arm check
After AP does arm checks, it can send a say, 5% (of some low amount that will not induce lift) throttle to all motors.
Compare the RPM and AMP draw against each motor. This could indicate a fault in a motor then pre-arm fail.


(makeflyeasy) #11

Does VESC now support UAVCAN?


(ACPUK) #12

As far as I know, not directly as it is now. I am ordering some to dev with and see if I can get them to work with UAVCAN. Not sure how long this will take though.


(David Buzz) #13

Vesc hardware clearly has can bus connectors, and a can bus software stack, so it’s completely capable from a hardware perspective.
It’s just a software implementation detail at this point to make it work. This line is a clear and obvious understatement.


(Jean-Philippe Hell) #14

Hello @DavidBuzz,
I’ve just came across your vesc integration proposal and as it happens I have a VESC 4.12 on my desk.
I also have knowledge about CAN and embedded software development, and I am currently without professional activity.
So my plan is to eventually add UAVCAN support to the VESC software, if that has not already been done.
For that purpose, I also ordered the latest Pixhawk 4 FMUv5 which should arrive next week or so.
I already started to look at Benjamin Vedder’s code to see where and how I could integrate the uavcan library, and also found that the libcanard would be easier / faster to integrate.


(David Buzz) #15

I support your endeavour, and will happily assist where I can , discuss or review any code you get, and help you get it PRed if i can when it’s ready.
The pixhawk2 is a much wider used platform, it’s a stm32f4 by default, and should ultimately be the platform you target. I know little about the ‘holybro pixhawk 4’ other than to say it seems more like a pixhawk1 with a faster cpu stuck on it, so let’s call it a ‘pixhawk 1.5’, as that is closer to the truth.