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-sy...) 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*