Greetings - I have been following this site for some time and I believe that it is time for me to stick my toe in the water. I am an electrical engineer in my day job and I design the commercial, industrial, and military equivalent of ESC's for various applications. I have designed the schematics, pbc's, and written the complete firmware (some from application notes, some from scratch) for a number of different applications ranging from 10W applications to 1kW applications (all relatively low-power) and have interfaced with customers using UART, CAN, and I2C. Most of my experience is with the dsPIC33F series microcontroller.
Though I have adequate experience with the ESC design itself, I lack any real experience with RC or drones besides my own tinkering (I have a Twin Star 2 flying with APM 1 w/ Oilpan). As a result, I really need feedback for hardware features before ordering any hardware so that I'm not stuck with a first revision that few can use without modification.
I see two potential markets, planes and copters. The primary requirement of a plane is high-efficiency while the primary requirement of a copter is high current capacity, quick response, and weight. Correct me if I'm wrong here. My current interests (and, thus, my development time) lie with the high efficiency mindset. Most of the hobbyists that I have seen on here equate long flight times with large capacity batteries. Since the motor consumes a majority of the energy contained in the battery, even modest improvements in efficiency can have drastic effects on flight time. It would be great if the same board could work well for both applications, so it might be smarter to design for a copter and just use different firmwares, much like ArduPlane and ArduCopter.
A question that many of you are surely asking yourselves is "why not just use ESC32?" Some time ago, I saw the post regarding ESC32 and noted a couple of things that interested me about the project. Unfortunately, only the software is open-source, so that gives us - the potential community - little incentive or ability to improve the hardware. I also noted that the board was 4-layer, which - even if the source is published - most of us don't have a full version of Eagle PCB to edit 4 layers anyway. ESC32 also has a lack of a couple of features that I really wasn't sure about. I'm not knocking their design, I think it is great! In fact, I saw their design and took inspiration from many of their features. They really did a fantastic job! The tiny physical size of the ESC32 really suits their project. I just don't believe that the design is very accessible to the community at this time.
I have taken the liberty of creating a schematic and layout (not quite complete, just need to add I2C hardware). I made some design decisions, but I am open to changing those if I can be convinced that the community needs them changed.
So, now the proposal, reasons behind some design decisions that I have made, and a request for input (hardware input is most valuable at this point since I'm not working on software just yet):
- Complete open-source ESC hardware and software using the STM32 platform
- STM32 physical circuit does not currently conform to ESC32. I wanted to make these code bases compatible, but ESC32 uses a timer other that TIM1 for the PWM output. Using TIM1 as the primary FET controllers allows PWM on top-side and bottom side (you can use this to reduce losses), automatic dead-time insertion, and provides other benefits.
- STM32F103V8 (any STM32F103x8 would have worked)
- Low-cost development tools, $22 (http://www.digikey.com/product-search/en/programmers-development-systems/in-circuit-programmers-emulators-and-debuggers/2621880?k=st-link) vs. the dsPIC's ICD3
- ARM GCC as the compiler (I like CooCox for the development environment)
- SWD programming/debugging is a given
- I2C support
- Does it need to support both 3.3V and 5V logic or just 5V?
- Power supply
- Should the STM32 3.3V requirement be supplied by an on-board voltage regulator or should it have an external supply requirement?
- Should the ESC supply the typical 5V/2A output common to many ESC's? This can add considerably to the board space requirement, but having a power supply for your servos that doesn't require an external BEC can be useful.
- What is a reasonable voltage bus range requirement? Right now, I'm targeting 6V-18V b/c I believe that this range takes care of 95% of the potential market. Going beyond that in either direction has the potential to add cost.
- CAN support
- This isn't currently in the works b/c it adds to board space, but if there are many applications that demand it, then it should be considered.
- PWM control
- As currently designed, will work with a 3.3V or 5V input
- Current limit
- Uses a shunt resistor coupled with an op-amp circuit that allows precise real-time current monitoring. On an I2C bus, this capability could be used to report the real-time current back to the controller (ArduPilot or any other interested party).
- Clock precision
- A precise clock requires some type of external oscillator. The STM32 internal oscillator is rated to be within 1%. This will affect things like closed-loop actual speeds, pwm frequency precision, and any reported values related to timing (such as reported speed). It will also have some implications on UART maximum communication speeds.
- The primary clock speed is limited to 64MHz when using the internal oscillator rather than the 72MHz capability of the part. This should not be an issue since there is plenty of processing power on-board at 64MHz.
- UART
- Full FTDI access to the USART pins, just as the open-source community requires. I'm sure that a CLI could be implemented using this.
- Gate resistors on all FETs
- This probably sounds crazy to some of you, but it gives a precise control of the FET turn-on characteristic. Turning on the FET slowly (high gate resistance) increases losses on the FET, but drastically reduces the high-frequency noise on the voltage bus. Turning on the FET quickly reduces FET losses, but drastically increases noise on the voltage bus. This has a large impact on microcontroller resets, bus capacitor size, and a host of other noise-related design decisions. Just mind your dead-times, a slow FET can really be a hazard if your dead times are too short.
- Accessibility
- 2-layer boards. It makes the board larger, but much more accessible to the community!
- Low component counts
- Ease of programming and configuring the board for an operation on a wide variety of motors, from the simplest RC use to the most complex power-monitoring and reporting.
- Design that passes batchpcb DFR so that the board is easy to manufacture (cheap)
There is more, but I'm really trying to keep it hardware-centric at this point. What I would really like is for some number of people express interest, we create a google group, share eagle files, and really get it going. It would also be great if we could put some cash together for the first couple of part and board buys so that we aren't sending UPS and digikey wads of cash for 1 and 2 part orders.
Thank you for reading through this looong post. I will keep an eye on this post and will be responding conversationally. In about a week, I will re-post any results and - hopefully - we can create a community around this idea!
Jason
*EDITED TO ADD google groups page created for this project is located here*
Comments
Great idea, much needed for multicopters, especially the larger ones with large propellers that have a response lag anyway. How about optical isolation as I like to keep the autopilot and on a seperate supply from the motor/ESC circuit.
I also vote for the 4 layer PCB.
Also, for the modular approach: I think the OpenBLDC design files are available to review, but the project lost steam and never invested time in the power stage, relying instead on deconstructing other controllers to use their power stage, not a good long term solution...
The same design strategy is used on another much larger open source ST ESC too. The Tumanako project has been developing an ESC for EV's and has code available for IFOC, and other control strategies:
http://sourceforge.net/apps/mediawiki/tumanako/index.php?title=Moto...
cool.
CAN: in response to another post, I also agree CAN is a better bus...but, no ESC's support CAN, so no controllers do, since no controllers support CAN no ESC's do...repeat loop - several controllers now use the F4 and supporting CAN is now a smaller leap, so I vote for finally having a CAN ready ESC PCB, the incremental hardware cost is minimal
single pcb multiple ESC's: echoing another commenter, I don't agree with this approach either ( failure reasons, limits ESC to only one multirotor config, etc.) - maybe as a derivative design, but certainly not as a first rev dev platform...
my vote is actually for more modularity than what was outlined - separate the power stage from the controller like Castle Creations, Turnigy DLUX, OpenBLDC, and really most of the decent BLDC ESC's for any application - the ESC power could be scaled up as needed and this would open up the ESC to a much wider market, and I don't think the weight/size penalty is very significant if designed properly
Hi great idea!
My five cents:
Do not integrate BEC at all, add galvanic isolation instead.
CLI for setup would be ideal
Current measurement via shunt is ok, but there must be posibility to calibrate it.
Add self test routine to check FET's, will save many if FET failed (mikrokopter ESC does this)
Use most ordinary and solderabe (no bga, dfn etc) components as possible
Make a kit (bare PCB and components in bag) for sale
I'm also really really interested in this. I'm already working on an external Traditional Helicopter Governor which would simply drive a standard ESC. Obviously integrating the whole thing makes a lot more sense.
I think we should use a modular approach. We will probably need a few different physical boards, but they could use common components, and sharing blocks of code.
1) Single ESC for Helis and Airplanes
2) Twin ESC for Helis and Airplanes
3) Multicopter ESC with modular power sections, up to 8. Basically a central board with power sections that get soldered on, and are replacable. I want to do away with PDB's, but I also don't want to have to replace an entire Octo board if one power section fails. This also allows for some choices in amp ratings. Could offer 20 and 40 amp power sections, but a common hub.
I would also like to have a switching BEC on a daughterboard, offering a few choices in size, as well as modularity. 3A is plenty for most multicopters, but may want up to 5A for a gimbal. Airplanes would also want at least 5A, maybe more. Helicopters would need... up to 20A.
And actually, that brings us to a good point. We may need two voltage levels. 1A at 5V, and then 3, 5, 10 or up to 20A at a higher, programmable voltage level. Could be 5V, 6V, 7V? Is this feature creep, or can we accomodate all this?
One solution I guess is just require heli guys to use an external BEC, or HV servos. I'd be fine with that. But still, I think a 5V 1A supply on a linear regulator would be fine for powering the APM, and then a switching regulator up to 5A, programmable voltage should be fine for all the other loads. It would be easy and cheap to put a small linear 5V regulator on just to supply the APM with the BEC is supplying 6V for gimbal servos.
One of the biggest reasons to do this is to have error reporting back to the APM. Notification of engine failure. I also want to be able to pass load information to the the ESC to assist in the RPM regulation. Helicopters want to have one set RPM level that is rigidly maintained. Say 1800rpm rotor speed. Current ESC's sort of already do this, but struggle a bit since they don't have any load feedforward information. They either have soft tuning, and thus can sag, or high tuning, but pulse the motor which causes a waggle in the tail.
I would also like to see the option for 2 external RPM sensors, to measure actual rotor RPM directly. This is important on a helicopter, because even after engine failure, a helicopter can glide if it can autorotate, but the APM needs to know the rotor RPM to do this, and the rotor is seperated from the engine by a one-way clutch. The motor can be stopped, but the rotor still turns.
Now, this is really easy, all I need is 1 or 2 pins with hardware interrupts. I already have code that does this on an Arduino.
I'd also volunteer for the "high level" code. I program industrial variable speed drives and have a pretty good handle on this stuff. What I'm talking about is, the APM sends an RPM command, everything that happens between there and the ESC FET driver section. And also, I'm already underway on this stuff with my ArduGovernor.
Thinking about it more, all we really need is a central brain, and then have power-section cards 20A, 40A, maybe 60 or 80, and then 100A for large helis. A single engine is just a brain, and a single power section card. Twin engine, two power sections, and then up to 8. The hub could be sized so that you couldn't fit 8 100A cards, that's fine. The only question is, how to pass power to the cards in the most efficient way?
Could we do Opto-isolation? Most good large speed controls are opto isolated.
You guys might want to check out this project: http://open-bldc.org/wiki/Open-BLDC
It looked very promising at some point, and had a great guy behind it.
This is great.
I hear angels singing in the background.
I2C is great but where is the love for SPI?
SPI is way faster and less complicated to implement in code.
I think moving away from a 4-layer board would definetly increase the size too much.
Having an onboard BEC is almost a must have.
I would certainly be interested in super fast response multi-rotor ESCs. I saw someone else suggest multiple ESCs on a single PDB, but I don't think that is a good idea. What happens when one fails? Replace the whole board? Suonds expensive... However, having some sort of power distribution board like Mikrokopter would be killer. I will be following this project closely.
Definitely a SBEC.
I don't know if its possible but maybe hardware that supports different firmwares allowing one to choose between car/plane/copter mode with a simple firmware switch.
Jason, it sounds like you have most of the bases covered on a vital component that most hobbyists have little understanding of.
CAN - I'd table it for now and poll if the community needs it. I2C seems to be the hot tickett now.
JAB has a good point, though a single ESC is enough to get running and develop, putting 4 of them with an integrated PDB (including fuse protection) would really shake things up.
A new board would have to exist for each multicopter variation, 3, 6, 4, 8,... It would make a cleaner platform. It would be a bummer to have a failure on it and have replace the entire board.
OR.. a board that would take ESC modules, controller modules, etc.. Sorta like a LEGO base for multicopters. The motor connections would be part of the main board. Hmmm...(cue up the creative far-away stare...)
-
3
-
4
-
5
-
6
-
7
of 7 Next