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
Nice! Have not seen it on the Store.
I think the development of the opensource ESC system needs to have in consideration this kind of modular integration in the design of the boards
jbabio, we already have board that allows you easily to change ESCs if they are getting defective. Our goals are to create an ESC that can fit on common size of 25 x 37mm. Most of ESC are on that size and they will all fit on this PDB board.
I Vote for the circular design for power distribution, servo inputs and motor connections for wiring simplicity with shield-type ESC mounted, this way changing a defective ESC will be quite straight forward and easy to perform on the field.
Also, the modular design allows you to use the same "Motherboard" for the different multicopter configurations (tri, quad, hexa, octo) so you can start with a small tricopter and purchase more "ESC shields" and motors as you progress (or afford for them)
I think that mounting the ESCs in the centre is better despite below the props they get cooler because of the lost of efficiency and stability due to turbulence. I've mounted the ESCs on the central plate of my heavy octo (CarbonCore Octo 1000) and have no heat problems at all (Himodel Pro 40A + T-motor MT3515-15 400KV) and the arms are completely clean because I run the cable inside them.
Just my 2 cents.
This is a very interesting proposal. I have some suggestions:
I would stay away from multiple ESCs on a single PCB. As ESCs tend to be a common failure point (due to the electrical stresses on the components, even when well engineered), I would like to avoid junking three good ESCs because one failed of a quad set. I am assuming SMT technology where the cost of a repair would exceed the cost of a replacement.
2-way communication between the ESC and the control board is desirable, even if it means abandoning the classic hobby servo interface. The use of I2C or CAN was mentioned in the original post and should be incorporated. Of course it is possible to have a pair of interfaces: A classic hobby servo interface for the flight controller to control speed and a separate 2-way interface for other control and status information. The user need not use the 2-way interface. One aspect of current ESC design that I find troublesome is automatic shutdown when certain fault conditions are detected by the ESC: low input voltage, over current, over temp, etc. While in many situations it may be desireable to shutdown the ESC automatically to protect it or the motor, in a multi-copter environment, such an autoshutdown could mean the loss of the aircraft. It would be much better if an ESC, when detecting a fault condition, would simply report it to the flight controller (and through telemetery, to the operator) and allow the decision of what to do about the fault to be made at a higher level.
With an ESC that is designed for multi-copter use, the classic servo interface also leads to, perhaps, more wires than necessary. Again, with a I2C or similar control interface, a single bus with enough bandwidth could be used to control all ESCs with a single connector on a matched flight controller. The control and feedback signals could be bussed from the flight controller to each ESC if the connectors are chosen carefully (I am thinking flat ribbon connectors with the cables fed through each connector. If it turns out that multiple ESCs on a single PCB make economic sense, then there could be a single cable between the flight controller and the ESC PCB (or they could plug directly into each other, like many of the DIY Drones components do now).
Just some thoughts. Good luck.
Would adding weight out at the motors not make it sluggish to respond? All weight needs to remain as central as possible.
regarding the "ESC in the prop wash" - wish:
This are my thoughts on that:
1.- beginners: easy to damage ESC
2.- pros: hard to waterproof
3.- everybody: if bigger than motor, reduces efficiency
4.- good ESC's don't need that much cooling anyway - if you need that much cooling - more than the gentle "draft" around the multirotor - then the ESC's are most likely awfully inefficient.
I would like to see a circular design to mount under the motor, and perhaps split the design to two boards, one for the controller part and one for the mosfet drivers and bemf circuit. this way it would be maximum flexible as one could add power stages to suit their needs. a board diameter of 35mm would fit most applications.
I don't get the "bec" size/cost arguments. I have a 10S, 7.5A rated uBEC that is about 1" x 1-1/2", and weighs 69g. It's nothing.
The design really should include an optional BEC on a daughterboard. It will reduce wiring further.
You are right about the MOSFT and BEMF sense resistors, however, the BEC/voltage regulator can become physically large as the input voltage goes up. Keeping the batteries to 4S or lower helps keep this circuit small. At a later point in the design, I'm sure that we will be increasing the voltage range, but we are just getting started, so I think we are ok starting around 4S-5S max. We will be posting significant milestones on the blog, so it should be easy to keep up.
I'm quite convinced that ESCs should be in the prop wash, so I don't think physically embedding them into the centre of a quad is a good idea.
Primarily because it's the best way to keep them cool - no point in adding fans when there are already four to eight of them.
However, this also keeps the high-current-high-frequency switched lines as short as possible.
- The wires from ESC to motor are a much bigger source of EMI than the wires from battery to ESC, as they don't (can't) have any capacitive smoothing and the ESC input generally does.
More specifically:
If a *copter ESC has any kind of 'ramp-down' or other backing-off for overtemp/overcurrent, it must have a way of telling the flight controller about it. Otherwise the FC is just going to ask it to ramp back up, and maybe crash the copter - so the hardware isn't saved anyway.
On the 4S-8S voltage front:
Am I right in thinking that aside from the BEC, the supported voltage range is just down to the choice of MOSFET and back-EMF sense resistors?
What I'm asking here is whether it's plausible to have a single design with a list of MOSFETs and sense resistors to select for different voltage ranges.
-
1
-
2
-
3
-
4
-
5
of 7 Next