Skelecs and a custom BLDC controller

Well! I’m now coming towards the end of my work placement at Imagination Technologies (next Thursday to be exact…) and having accumulated a pair of pay-checks, I’ve spent some of my spoils!

What on you ask? As ever, Aliexpress. I’ve devised a new project that will combine my useless need for electromechanical transport, along with my skill (or luck) with electronic engineering. It also gives me a chance to expand my knowledge in the field of electrical engineering and keep up with current motor technologies (…yay?). The project is!

Electric roller skates! (Or as I call them, my Skelecs – lame I know.)

Having been roller skating for over a year now and having taken part in two major skating events (internationally!), I thought it was only appropriate for my next method of personal transport to be based around skating. After completing the ShockSoc trike build, a thirst for electromechanical transport was reignited and I just had to design myself something and that took form in electric skates.

While I’m not a mechanical engineer by trade (or any notion of anything really), I generally thing as a cloud of mechanical parts, thinking up ideas without real thought on the implementation. While this is not the “legit” way of doing mechanical design, it at least gives me an idea of what I’m expecting from a design and gets me a step closer to a final design. A multitude of ideas became apparent for the design of electric skates, though some stupider than others!

Current inventory:

  • 2x 4″ sensored hub motors with tires – the smallest hub motor tire combinations I could find! The size is apparent in the power of the motors, 120W at 24V! (Aliexpress link)
  • 2x 250W Brushless DC motor controllers – these were the cheapest of cheap and will only be used until I finish creating my BLDC controller! (Aliexpress link)
  • 2x 6s 2650mAh LiPo Batteries (22.2v) – Some of the cheapest LiPo batteries I could buy off Hobbyking, the cheapest of course having half the capacity at a saving of ~£2, not worth it! (
  • 1x Turnigy LiPo charger – up to 6s (
  • Custom cut steel, courtesy of Austen Knapman.
  • 4x 40mm rubber castor wheels ( – Sadly relatively lowly rated for load capacity though the only ones I could find with a total height of ~50mm.
  • My Seba skates! These are attached to their frames by two bolts seperated by ~170mm. This allows easy attachment to whatever frame I design!

Cue the low quality 2d flat drawings thanks to my inability to CAD…

Idea 1: Front wheel drive with a rear castor wheel
This was my initial idea and seemed great until I considered the effects of the high centre of gravity associated with being stood ontop of a relatively large castor. I do think this would’ve worked if I could’ve found some castors small enough to bear the load of me along with the skates, while being made of a nicer material than solid plastic.

I said my drawing skills were poor…

Idea 2: Front wheel drive with dual rear castor wheels
The easiest way to solve the centre of gravity issue? Add two castors! If the castors are spaced far enough apart, I envisage the centre of gravity issue being much smaller, given the fact that there will be one for each foot. Steering would be accomplished by twisting ones ankle in the direction they wish to move. Once the castors are pointing in that direction, the hub motor will also be pointing in that direction, moving the user… in the set direction!


Idea 3: Single rear wheel drive with front omniball
Whats an omniball I hear you say? Essentially the greatest idea for a castor replacement ever, I guess. The idea is that instead of having castors where the whole wheel assembly is connected at an offset to the main framework (to actually allow the wheels to rotate when directional force is applied), the wheel assembly is replaced with a gigantic ball, partially encased with ball bearings between the ball and the casing. This allows for seamless direction change ( Sadly, such cool technology comes with a price. The omniball assemblies cost £20 each which is relatively cheap considering how cool they are I guess though the main reason putting me off is the fact their made of solid phenolic resin and have a maximum rated speed of 1m/s.


Idea 4: Single rear wheel drive with dual front castor wheels
As of yet, this is my most promising idea and is what I’ve bought my materials on! Like above, the hub motor is at the back of the assembly, behind ones ankle. At the front, are two small castor wheels. The main reason for moving the hub motor to the back of the assembly is to aid in steering. I find it much easier to point my toes using my angle as the pivot point, as opposed to using the ball of my foot as the pivot point and twisting my ankle. The downside here however is if too much torque is applied from standstill, the rider is more likely to fall backwards smacking the back of their head on the floor, ouch! Fortunately, once I’ve built the actual frame, swapping the orientation of my skate boot should actually be relatively easy, allowing me to test out both forward and backward mounted methods.


Final idea
I’m still quite set on using the single rear hub motor with dual front casters. I don’t think the falling over backward problem will be particularly apparent as the users heel (and main point of downward force) will be quite far in front of the hub motor (around 60mm). Not forgetting the fact the hub motors aren’t THAT torquey! The front castors however are a little worrying as they have a maximum supported load of 20kg/castor. This should be less of a problem with the rear wheel drive version as the downward force at the toe should be less than the force at the heel. This becomes more of a problem in the opposite configuration.

Control! The one word that rings hell in an engineer who isn’t up to scratch on their maths skills. Fortunately, I don’t (as of yet) mean in a transfer function manner and I mean how on earth am I going to control the skelecs?! Obviously for safety reasons, I’ve put quite a lot of thought into this one, how I can keep the skates safe at full power in case of potential problems. I’m currently thinking of using a wireless handheld controller with a simple joystick interface (only actually employing the Y axis), communicating with two wireless transceivers on each skelec. The issue here comes with what wireless module to use? With a plethora of choices ranging from simple ASK modules, to full network style 2.4GHz modules, I decided to go down the middle with a set of 3x HC-12 USART to 433MHz modules. Here in the UK, the 433MHz seems to be legal for public use (depending on what source you read…) and the HC-12 modules are pretty easy to use as they abstract the actual radio interface with essentially a wired equivalent USART between two USART transceivers. Connect sender(Tx(MCU) to Rx(RF) and Tx(RF) to Rx(MCU)), along with the same on the receiver side and voila! Easy wireless USART communication. That thankfully sorts the wireless side out but not the safety side.

No electronic system can be completely trustworthy with no potential bit errors. It is therefore important that the system as a whole has a standard fail safe condition that causes no harm to the user. In this case, I’ve decided that under any error conditions, the skelecs will come to a gradual stop until power cycled. This means the user will automatically come to a stop under error conditions, reducing the risk of the skelecs sticking in a high power state where the user has the inability to stop! I’ve decided on a packet structure that will consist of:

Packet structure

While the packet structure itself is simple, the transmitter will be sending these packets out at a predefined and set rate. If the receivers timeout with respect to receiving a packet, the skelecs will enter the failsafe mode and need to be power cycled to work again. This means if the transmitter runs out of battery or malfunctions, the skelecs will be able to safely bring the user to a stop while the problem is debugged. As there will be no physical method of braking (disc brakes/hub brakes etc.), braking will be done using the hub motor. With the hub motor being gearless, the motor is always in contact with the outer hub meaning lossy regenerative braking can be done or worst case, crippling the motor commutation by energizing the wrong phase at the wrong time! The packet type is quite self explanatory and will allow for up to 255 different packet types. As of yet, I’ve thought of control packets – for example changing acceleration curves, and a Throttle/brake packet. The Throttle/brake packet will sit at 127 when idle. A deviation in the positive direction (127+(hysteresis)->255) will cause the skelecs to move forward at a rate proportional to the magnitude of: map(this packet – (127+hysteresis), 0 -> 255). With a deviation in the negative direction (127-(hysteresis) -> 0), will cause breaking and eventually reverse (if I implement this in my own BLDC controller). The checksum will be a sum of the header and the packed done under 8 bit unsigned arithmetic. The skelec controllers will also have slew rate limiting (most likely in the form of a first order LPF), to aid in reducing user damage at high acceleration rates! The level of limiting will of course be a defined parameter that is easily modified, giving the opportunity of a multitude of acceleration curves. There will also be the ability to set maximum speed if required! I’m assuming the controllers that I’ve purchased will take an analog voltage for the throttle control so for my prototype, I’ll be using STM32F030 TSSOP20 microcontrollers, connected to my HC-12 module through USART, outputting the control analog voltages using a PWM DAC. I’m hoping that I don’t need any form of level translation but if I do, I can add a simple RTL transistor inverter stage on the output and output inverted PWM from the STM32.

PWMSpicePWM DAC with volatge translator, note the minor error due to the higher impedance of charging vs discharging the capacitor! The discharge path has lower resistance (through the MOSFET).

BLDC Controller
Now for the actual electronics! BLDC motor controllers may seem magic but they’re actually relatively simple in operation. For sensored motor control where the exact position of the rotor can be fed back to the controller, all that is really required is a state machine where the activated outputs are chosen dependent on the current rotor position. For a 3 phase motor, to move forward (in drastically simplified terms), if the hall sensors indicate the rotor being over phase A, phase B should be energized, until the hall sensors indicate being above phase B, phase C should then the energized and phase B de-energized, and so on. This is actually known as 120 degree control. A more common and efficient method is 60 degree control where multiple phases are energized at different times during a rotation. 60 degree control has 6 energizing states. Speed control is added by PWM’ing the outputs to the motor phases. As a motor is inductive, this inductive nature opposes large changes in current, essentially smoothing current. When pulses of current are applied (at high enough frequency), the inductance of the motor (along with mechanical inertia) act to smooth these pulses, giving an observed current equal to the maximum motor current multiplied by the duty cycle. In easier terms: smaller duty cycle = lower average current. As torque and current are proportional in a motor, lower average current = lower average torque, which under loaded conditions means more time for the rotor to get to the defined speed.

There are a multitude of online examples of BLDC control, predominantly from the major semiconductor manufacturers (TI, ST and Microchip to name a few…) with multiple semiconductor companies offering all the required parts. My design is based around an STM32F030 IC as the controller, a IR2136SPBF MOSFET driver with all required level shifting, dead time generate and fault management, along with 6x IRFS3806PBF power MOSFETs in a D2PAK package. Other than my n00by 100W LED driver, this will soon take over as the highest power design I’ve done! To accomodate the high currents that will be used, thick PCB traces have been used and are perforated with vias to reduce impedance and improve heat dissipating ability.

Current version of the BLDC controller PCB.

The power regulation section isn’t particularly well heatsink’d so I’ll be making sure to not draw lots of power from the auxiliary lines. I’ll quite likely be heatsinking the regulators too. The MOSFETs will also require some form of heatsinking. As of yet, I’ve made room for small aluminium heatsinks to be attached to the backside of the PCB for each MOSFET and I’ll quite likely add a large heatsink to the tops of the MOSFETs though the efficiency of this will probably be small due to the thermal resistance of the actual plastic cases.

There are three voltage domains: 3.3V, 5V and 12V. The 3.3V rail is used for the microcontroller and supplying power to the throttle input (which I will discuss later…). The 5V rail will supply the power required for the hall effect sensors in the hub. If the controller is working in sensorless mode, this rail will likely be unused. Finally, the 12V rail will be used to supply power to the gate drive IC, hence the DPAK choice of package, along with supplying to the 5V and 3.3V regulators.

Throttle input
As I’m going to be using this controller predominantly for myself, I’ll be defining the throttle type at build. I’m using PA3 as my throttle input of course, with a series input protection resistor! PA3 is both an analog input and an input to one of the internal timers. This allows me to control the controller in multiple ways. Firstly, by a standard potentiometer producing an output voltage between 0 and 3.3V, secondly by a standard servo output. The internal timer can be used to measure the pulse width of an incoming pulse and translate that to the required value internally. Finally, PA3 is also the RX of USART2 (surprise surprise!) meaning I can connect my HC-12 modules directly to my motor controller!

Hardly the tidiest schematic!

I’m waiting for a couple more parts to come in the post but once they arrive, I’ll be sending all my PCBs off for manufacture (including a few for the Phobass)!

Current status
As of now (6/9/15), I’ve purchased the steel required and that will be arriving back at home shortly. I’m yet to purchase nuts and bolts but I’ll likely purchase them from my local hardware store as popping into town is much easier and more efficient time wise than waiting 2-3 days for post to arrive!


Keep tuned for more updates!


3 responses to “Skelecs and a custom BLDC controller

  1. Pingback: Skelecs: Part 2 – The Layout | Harris' Electronics·

  2. Pingback: Skelecs: Part 6 – The final frontier | Harris' Electronics·

  3. Pingback: Powered Skateboards are Passe; Skelecs the New Hotness | Hackaday·

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s