I wanted to bring everyone up to date on where the ESC32 development is at this point. After a lot of testing of the version 1 design, we found that operating under high current situations, current spikes caused by commutation were introducing a lot of noise on the digital side of things. In the worse cases, this could lead to clocking issues causing the MCU to reset or worse, lock up. Of course if that happens you will likely cook a motor.
So, back to the drawing board (CAD actually). After a lot of trial and error, I came up with the version 2 design. It manages to keep the high current paths much shorter and thicker as well as keeping the analog and digital ground planes completely separate. This new approach is now working quite well with as much current as the FETs will handle. I took this re-design opportunity to add CAN Bus support with an optional CAN transceiver chip onboard. Additionally an external shunt resistor was added to improve the accuracy of current measurements over the original internal PCB trace shunt. All of this without loosing any prior interfaces or functionality.
During the same time a lot of work went into improving the firmware's operation and adding new features.
The CLI has been expanded and gives you access to all tunable parameters via the UART port. There is also a binary protocol for high speed machine to machine communications up to 921600 baud. And now Dallas Semiconductor's 1-wire protocol is supported over the PWM IN port. This means that the flight controller can bi-directionally communicate with the ESC over the existing PWM IN lines. This can be useful for setting run modes and parameters pre-flight or downloading operational data post-flight. Anytime the ESC is not in the run state, communications can take place. There is a future opportunity to allow firmware updates over the 1-wire protocol as well.
Closed loop RPM mode has been implemented. The idea is that the throttle maps to RPM directly in a linear fashion and the ESC works to achieve and maintain the requested RPM with a closed loop controller onboard running at 1KHz. The ESC utilizes a feed forward augmented PI controller to get you to the requested set point as quickly as possible but still remaining within the set current limit. There is also an experimental regenerative braking feature which takes excess motor speed and turns it into current flowing back into the battery. Closed loop mode can be very useful when implementing advanced predictive attitude controllers on the FC which will require consistent, predictable performance from the motors.
Another interesting feature is what I call the virtual current limiter. The problem with a lot of hobby ESCs is that they have to be careful of how much current they allow the motor to draw during acceleration events. Most of them use some sort of throttle filtering or smoothing to limit the throttle increases allowed at each time step. The amount of current drawn by the motor depends on the motor's size, RPM and prop load which is not known by the ESC and most do not have a current sensor. Since there is no way to know how much is too much, they have to settle on a conservative approach to avoid frying motors or FETs. This will ultimately limit the throttle response to something less than optimal and for multi-rotors, this is undesirable.
My solution to this problem was to give the user a way to profile the motor and prop being used on the bench. This data can also be looked up from a database that is being compiled of known motor/prop configurations. With this information, the onboard current limiter can pre-calculate how much current a given throttle (voltage) request will take at the current RPM, and if it would result in an over current situation, the implemented throttle request is trimmed to fit under the limit. As the motor speeds up, the current demand drops even if the requested throttle has not changed so the limit is re-evaluated at 1KHz trying to give the maximum amount of acceleration possible with the given restrictions. The results are the fastest throttle response possible while staying under the set current limit. Finally, if the profiling parameters have not yet been set, a regular PI controller is used to limit current. It is still better than throttle filtering methods, but not as good as the virtual current limiter as it is a reactionary strategy.
There are now also a lot of tunable parameters which allow the ESC to be used for non-standard applications. For instance, if you are using PWM IN for control, you can design custom parameters for the pulse width and waveform period. Current limits, start voltages, PWM output frequency many other settings can be made from the CLI, binary or 1-wire interfaces and stored in flash memory for future power ups.
I'm sure the first question will be how much current can they handle. The truth is I don't really know. According to their data sheet, the FETs are capable of 160A continuous. As a practical matter, there is no way you could come close to dissipating the amount of heat that would be generated at those levels. With large heat sinks you could probably run them over 50A continuous, but without any heat sinks the limit will be significantly less. In the end, the limiting factor is simply cooling. If you can get them into some prop wash or rig some sort of small heat sink your results will improve. I've been flying them for for more than 6 months with no heat sink at all, but my machines typically weigh less than 3Kg. As we get more test data in we will be better able to characterize the actual limits.
I'd like to thank all of the people who have helped test and even blown up motors to make this ESC possible.
ESC32 v2 specifications and features:
- STM32F103 72MHz 32bit ARM
- All N-FET design with gate drivers
- 2S through 5S battery voltage
- Option to power logic side via UART or PWM IN +5v
- CAN transceiver hardware support onboard
- Firmware written completely in C
- ARM Cortex SWD connector pads for real-time debugging
- Communications ports: PWM IN / UART / I2C / CAN Bus
- Communications protocols: PWM IN / CLI / binary / 1-wire / I2C** / CAN**
- 4KHz to 64KHz PWM out
- Current sensing / limiting with real shunt resistor
- Closed loop control modes
- Virtual current limiter
- Regenerative braking (experimental)
- Lot of available RAM / FLASH for experimentation and development
* rendering by Max Levine
** I2C and CAN drivers have not yet been written
Finally I have decided to release the source code under an open source license. Hopefully talented individuals will be able to help design new features and functions that everyone can use:
Comments
From a heatsinking perspective, the package plus board stack thickness for the FETs is almost exactly 1/4". With the copper clearance from the edge of the board, extracting some more heat might be as simple as a little TIC and some aluminium U-channel.
I'd like to add my voice in favor of the modular approach to higher-power and voltage applications.
Although I noticed a power rail anti-ringing capacitor in the test video, the board does not seem to have provisions for such a device. Naturally, it should be sized based on current load and rail inductance (length), but are you leaving this up to the purchaser? Or are you relying on zener feedback to the gate to mitigate potential avalanche voltages?
In fact the prototype was designed as two separate stages. There are approximately 9 signals and a ground that are needed to go between the two circuit sections.
Is there anything in your design (schematic or code) that would prevent it from being broken out into two pcb's? I have a 48V diy electric recumbent, and another hobby project I'm working on might be able to use the ESC32 as is - but both would benefit from querying torque and RPM info (CAN bus seems ideal). I have an EV running a very large Azure controller too. So, the possibility of learning one ESC platfrom by swapping in different power stages seemed very attractive. I'm not sure how realistic this desire is though. I know really large power stages are available as commodity items, but I'm not aware of any at the low end aside from taking apart a Turnigy dlux, so they would need to be built.
I know these are obscure requirements and outside the scope of your multirotor application. I worked on a multirotor in 2008, but it's a joke compared to what you and others have accomplished. I've been eagerly waiting for you to accept beta testers for Autoquad since I'd like to try a multirotor again (and learn the F4). I'm sure your current ESC will be fine for the multirotor, and understand the desire to minimize size. I noticed there was a nice wiki forming on the autoquad google project, and then it dissapeared - hopefully the project is still active...
If you're not making any money from the German manufacturing effort, are the pcb files and BOM available? I can run my own boards at http://dorkbotpdx.org/wiki/pcb_order/ and populate them.
Thanks
Hi Joe,
I think the price ranges are similar in the EU and the USA. Maybe we pay in Euros what you pay in Dollars. ;)
The decision was made because the network of people on the manufacturing part of the project are Europeans and one of the team members works with the factory on a daily base.
We also wanted to minimize the risk of failures, having control over the manufacturing, sourcing of parts and the test environment before they leave the factory. We wanted good quality and were rewarded by a failure rates of <1% which were sorted out by the factory.
Size and weight. Trying separate things more would mean bigger and heavier. This same design could be scaled up or down. If there is interest in a much lower power version, I could shrink things down enough where it could fit into a 1/2" tube.
You'd have to ask the manufacturer why they made the country decisions they did. I am not manufacturing or selling these ESC's nor do I stand to make any money off of their sales.
When I worked with a large ESC for an EV motor I noticed the IGBT block was a separate module from the (ST ARM) controller board - presumably so the design was flexible enough to allow different power levels (?). Many third parties produce IGBT blocks. I think the CC ESC's and Turnigy dlux use a similar strategy (and OpenBLDC?). Not questioning your design, since I am not very knowledgeable on ESC's. Can you elaborate on why you decided to not go with a more modular approach that might allow easy adaptation for different power requirements?
Since you're US based I'm also curious why you decided to manufacture in Germany. Was this option much cheaper than manufacturing in the US? I know CC and many others manufacture in China, so no hidden nationalism in my statement. But I rarely see people manufacturing in Germany to lower costs.
BTW, your work is very impressive. Thanks.
Here's a short test of the ESC32 on the bench.
Yes, a closed loop thrust mode has been planed for - linearizing thrust instead of RPM. As soon as I get some free time I will implement it. It should be easy as I have all of the required pieces lined up.
Bill,
Now I see what you meant by "some interesting developments this weekend" :-)
Have you considered direct current control, instead of RPM control? What the flight controller cares about is thrust and torque, which should be proportional to current. Thrust and torque are quadratic functions of RPM.
- Roy
-
1
-
2
-
3
-
4
-
5
of 6 Next