Malenki-ESC open source Antweight ESC

[MarkR]

Hi,

I've designed an open-source hardware Antweight ESC.

It is still under development, but I now have my first actual board made. It doesn't work yet because the firmware isn't finished.

* Three channels of DC motor drive (maximum current TBC, but should be at least 2A)
* Takes PPM/CPPM/ i-bus (and maybe S-bus) single wire signal from a RX (like drone controllers do)
* Open source hardware; open source firmware.
* Almost as small as a Dasmikro (about 24x26 mm)

I will post more information later. In the mean time,

Source code is here: https://github.com/MarkR42/malenki-esc



Schematic: http://vectrex.org.uk/mark/esc-marketin ... ematic.pdf

PS: apologies for installing R2 upside-down, all the electrons will fall out - I will do it the right way next time.

[MySolderIsOlder]

This is VERY exciting (or should I say 'ochen volnuyushche') news, Mark! Support for cPPM would make life so much easier, especially if/when HK ever get the OrangeRx R614XN back in stock. Best of luck finishing it off.

[LimaHotel]

Now THAT looks exciting!

[MarkR]

Now I have a strange issue.

I've got the ESC working and decoding PPM signals. They seem to work ok, my receivers will stop sending pulses when they lose signal, and after a short time then we turn the motors off (as you'd expect) to implement failsafe.

I'm now working on supporting serial protocols such as Flysky/Turnigy i-bus.

But using the Flysky I-bus protocol, the Turnigy iA6C (this one) continues sending pulses (with the sticks in their last known position) even after the transmitter is turned off.

This would be really inconvenient and violate the rules, because we can't implement failsafe, a spinning robot could keep spinning until its battery ran out.

I've got another receiver which is the Turnigy FS-A8S which doesn't exhibit this problem.

I'm guessing that the "smarter" telemetry rx is trying to be clever, or waiting for telemetry from the drone it's in (good luck) before it stops sending packets.

[Kyro]

menu, rx setup, failsafe... play with these settings... may help with your issue...

works only for the afhds 2a as the regular afhds seems to do it automatically if signal is lost

[MarkR]

Update:

What works/ is done:

* The motor drivers work. I've tested it with a spare N20 and it can drive it with no problem at variable speed in both directions.
* Tank-mixing
* The receiver can automatically decode PPM signals or ibus (Turnigy)
* I wrote some end-user documentation

What is still TODO:

* Decoding S-Bus signals (S-bus uses a different serial speed, inverted signals and requires some bit-twiddling)
* Make a better programming / testing system - because right now I have wires soldered on to surface mount pads
* Build a test robot!
* Fully document the hardware (BOM, assembly instructions, PCB manufacture notes)

I have made some very minor revisions to the PCB for the next batch to allow easier assembly and update the silk-screen.

If anyone is interested, the hardware design and firmware, etc, is all here: https://github.com/MarkR42/malenki-esc

[MarkR]

Another update:

* Firmware is mostly working, it reads PPM, ibus or S-Bus and will autodetect (there is only one rx pin)

I intend to build a robot with it shortly to see if it will actually bot

Here is a size comparison, left to right: £1, DasMikro2S6A (2-channel), Malenki-ESC (3-channel), €1

[Paulmchurd]

This looks awesome, however I’m a little confused. Does this only work through a single signal wire?

All 3 Signal wires are through 1 wire??

[MarkR]

Yes, there is only one signal wire.

Drones commonly use this, the signal wire speaks one of several commonly used protocols, either CPPM (which is several PWM signals multiplexed in time) or one of the serial bus protocols S-Bus or i-bus.

It allows more channels with fewer wires. I can incorporate more than three channels, for example, channel 5 I used as an invert switch in case the robot is upside down.

[LimaHotel]

So how does that work with regards to wiring it into a receiver?