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
I have one. Battery voltage sensing and power output compensation. I have found through actual thrust testing that the thrust is proportional to the voltage at a given PWM setting. When I compensated the PWM output for battery voltage the thrust output was constant over the battery full to empty range with in limits. This would of course need to be settable in the cli. For copters or planes it would be good to take a variable out of the system, which now is probably only compensated for with integrators in pid controllers.
Superb Jani! think about how much wires mess we will also avoid on top of all the nice exta this brings.
waiting to pass the order sir! :) hehe take your time destroying them first to make them as perfect as you can.
Dany
I would like this.
#1 Safety to how others fly with such.
#2 The ability to coordinate energies to make flight. Vertical or Horizontal.
#3 The play to find how much throw will destroy safely a small hobby that flies as best one can do such.
@Jani: Very exciting! Will this be able to hold up to 8 x 40A ESCs? I run a large octo.
@Kolin, that "components in bag" is must and it was one first things that I was thinking too. It will be rather easy to make bare PCBs and component bags for hardcore DIY people.
STM32 would be perfect platform to build it. There are many good development toolchains already for those. Prices are reasonable and availability is good compared to Atmel chips that are out from market manytimes.
Onboard current measurement is a must to make controlling as efficient as possible. Same goes on multiple control methods what Jason already mentioned like PWM, I2C, UART and CAN. SPI in other hand is something that I really don't see any reasons to have, yes it's fast and most of devices have it but it is also prone to interference. Interference especially is you have long cables and a lot of EMI around. So I would say SPI is good only for internal devices like Gyros, Accels and so on. Also it needs way too many cables compared to other methods (5 vs. 1 or 2). So no SPI outside of Flight controllers and their closeby electronics.
CLI for sure that's a must on all intelligent devices. And i would say that extra configuration should be able to send via I2C or what ever method as in protocol sentences. There are several good and light protocols that could be used for this and also making it's own protocol won't be a difficult task.
CooCox looks cool, need to check that more as we are working on several ARM designs now and need to have nice toolchains for those.
For Adam and others. Just a quick sneak preview of our new Power distribution that will answer on your call.
It can hold almost every 25 x 35 mm ESCs on market, PWM/I2C/CAN busses. It is stackable for 4/8/12 ESC systems.
Currently we are finaltuning it and doing some stress tests (eg burning them intentionally) to make sure that it's strong enough for all your uses.
About BECs, I don't see any reason to have BEC on ESC board. Why?? It's just waste of good space and components. Wasting space or components is just making production costs higher. You only need 1 uBEC or maybe 2 if you plan redundant systems.
Btw this board is modular board and it haves uBEC carrier on middle that can hold currently 2 uBECs. On top we can have another carrier to hold what ever extra electronics we want.
On next revision we will make small modifications so all comments are more than welcome, you still have time to affect in it's design.
Last but not least, bottom picture with 1 uBEC and it's carrier board:
I haven't seen much mention of cars, but I know I've thought of such a thing for my rover-to-be as well, especially one w/o a Voltage Regulator. Some things different about cars, like reverse, and some of the crawler/off-road specific ESC's have things like drag brake (motor hold @neutral, so you don't slide back down the incline), dual-motor control [w/ or w/o DIG (independent axle lock)] for motor-on-axle crawlers.
I'm not sure how much of this requires the same hardware, however, and how much of it is programming. There are some crawler/off-road ESC companies you may want to look at, like the previously mentioned Castle Creations line, or Holmes Hobbies (BRXL Waterproof is one I'm currently researching and it seems quite good), or Tekin.
Great project!
I agree, Flying Monkey, everyone wants something slightly different! To pare down the discussion into a bit more organization, I have created a google group. Anyone interested in contributing or following, head on over there and introduce yourself. I have created 3 threads, one for introductions, one for discussion of project goals, and one for common tool selection. After the common tool is selected, we will hopefully have an idea of the majority opinion on project goals and be able to start in earnest. Thank you all for the great response!
I think you just asked a group of kids what kind of candy they want, lol.
Me personally, I'm after high efficiency too. I want LONG flight times on my multirotors and want my esc to consume less power itself, and drive the motor with as little power as possible as well. High input/output rates too of course, flashed ESC's are SO much better! Two way communication for motor-out situation is a good idea, so is the multi-color LED for status. I do like the all-in-one esc idea, it would clean up my quads, tri, and hexas, but a modular design with a central power sounds like the best compromise. Keep up the good work!
BEC is an antique from the transition to electric powered systems. Let's let this terminology die now.
A Voltage Regulator (step up or down) that powers non-motor related components should have nothing to do with my ESC. Just control my motor to the best of your ability, that's all I ask of an ESC. I want it as isolated as possible, both electrically and thermally.
Actually, I would like to mount it on or near the motor, using the airflow of the motor to assist cooling, and to facilitate modularity and field repair-ability. Inputs should have enough capacitors to handle the long cable run out to the end of a multi arm from a battery in the center. I would like a nice bright multi-color LED to give me fool proof fault and status information, these could also double duty as effective navigation/low voltage lights when positioned on the motor.
This is an excellent project Jason, thank you. I hereby commit to purchase and test some unknown number of these ESCs as the project gets to that point.
-
2
-
3
-
4
-
5
-
6
of 7 Next