Hoverboards for Assistive Devices

Want to motorize a wheeled assistive device? What better than a hacked hoverboard with brushless motors, electronics and power.

Public Chat
Similar projects worth following
Cerebral Palsy (CP) is a disorder that affect a person’s ability to move and maintain balance and posture. CP is the most common motor disability in childhood.

Commercial motorized devices for children with CP (and other motor disorders) are very expensive, and are outgrown quickly. Groups like "Go Baby Go" take motorized toy cars and adapt them for kids by adding button and joysticks.

But, what I wanted to do was find an inexpensive way to motorize any Assistive Devices that is already wheeled, but not power driven. This would allow a new level of independence for the user.

As a robotics coach I know how to make things move. You build a drive chassis, and then add power systems and software. But, a hoverboard (HB) already has all the right elements built into a compact chassis for a very low price.

I took the challenge to create a generic Hoverboard drive system that could be adapted to most wheeled devices, and be run by a joystick.


My ultimate goal for this project is to develop an open framework for adding low cost power systems to unpowered mobility devices used by children.  I like brining "structure" to a range of existing solutions, so my plan was to choose a suitable mobility platform (in this case, the ubiquitous Hoverboard) and devise a strategy whereby tech-savvy hobbyists could add a power drive to just about any wheeled device.

I've teamed up with a Occupational Therapist who's function is to focus my goals and provide real-world challenges for me to base my solutions around.

I will develop and evolve requirements and interface spec's as I explore the world of assistive devices.  I will document the project progress here, and publish code on Github.

Here's an easy way to absorb this project in nice chunks:

My goal here is to show that the concept of using a Hoverboard to motorize an adaptive transport system has a WIDE range of applications.  Adding a power drive provides the user with new independence.  No longer will they be at the mercy of someone to push them around.  

I want the formulae to be simple.  1) Beg, borrow or make a basic wheeled device. 2) Reprogram a Hoverboard to accept joystick commands. 3) Pick the best joystick for the user, and 4) combine all three items together.

I am creating simple and inexpensive solutions for 2) and 3).  Along the way, I'll build some examples of how you can solve steps 1 and 4 on a case by case basis.

Currently I have two different prototypes.  One is based on an expensive  Jenx Multi-Stander , and the other is my own home-brew DIY concept.  Both demonstrate using a hacked Hoverboard as their "drive" system.  I used a hard-wired joystick for the stander, but then I developed a bluetooth Joystick interface for the newer DIY version.

Some teaser tech details:

Both prototypes uses a HOVER-1 ULTRA hoverboard, running custom firmware on the 2 original Hoverboard Motor controllers.  The first prototype has an additional embedded ESP32 based controller that interfaces with an external joystick, and generates motion profiles.   The second prototype has a bluetooth module added to the hoverboard, which takes commands from a custom wireless Joystick controller.

My next task is to get some user feedback on the joystick motion profiles.  I expect that I may have to play with acceleration rates, and time/velocity profiles for driving and turning.  

I'm currently only using about 20% of the full velocity available, but the HOVER-1 ULTRA is still very controllable.  I have implemented a simple P(ID) speed control to enable accurate speed across the full range of motion.  

HUGS Protocol Doc.pdf

This is the specification for the HUGS Communications Protocol.

Adobe Portable Document Format - 412.99 kB - 04/17/2020 at 15:44


  • 2020 Hackaday Prize review.

    Phil Malone08/16/2020 at 02:47 0 comments

    Since I've entered this project in the 2020 Hackaday Prize (UCPLA non-profit category), It's worth reviewing the judging criteria to make sure I've got everything covered.

    According to the rules, the first step is to be included in the Entry round.  

    Entry Round: At the close of the Entry Round Period, a panel of qualified judges
    appointed by Sponsor will select up to one hundred (100) submissions to advance to the
    Final Round based on the following four (4) evenly-weighted judging criteria:

    1. How effective of a solution is the entry to the challenge it is responding to?
    2. How thoroughly documented were the design process & design decisions?
    3. How ready is this design to be manufactured?
    4. How complete is the project?

    In my case I've submitted my project for:
    The Best Nonprofit Solution, sponsored by United Cerebral Palsy Los Angeles (UCPLA).  

    Their open challenge is for High Quality Tools and Devices For Creative Expression:

    Cerebral Palsy is a group of disorders that affects movement, muscle tone, or posture.
    Generalized symptoms appear during infancy or in early childhood and include impaired movement, abnormal reflexes, involuntary movements, unsteady walking, trouble swallowing, or eye muscle imbalance, which makes it difficult for both eyes to focus on the same thing.

    This challenge seeks new designs for adaptive tools like tripods, workstations, trackballs, or joysticks that can be made affordable and open source. The purpose of these designs is to give individuals with cerebral palsy and/or other physical challenges greater independence in their lives. 

    So.. It's time to self-evaluate, and see if I'm covering the goals of the evaluation criteria.

    Read more »

  • Log #12 The "BluJoy" Bluetooth Joystick interface.

    Phil Malone08/14/2020 at 19:53 0 comments

    In Log #10 I experimented with Bluetooth modules to see if I could make a low cost wireless Joystick controller for my hacked hoverboards.  My early success led me to design a custom PCB that could satisfy several requirements:

    1) The board must be able to interface to either a micro-switch, or potentiometer based Joystick.

    2) It must be able to generate smooth (trapezoid profile) velocity commands .

    3) It must provide a fool-proof Bluetooth interface from the joystick to the hoverboard. 

    4) It must run on batteries, but have a long operational life (> 50 hours) and standby time (> 30 days).

    My first prototype is shown below.

    It may not be immediately obvious, but the board is pretty small.  It's just 1 1/4" x 3 1/4".   

    What you may find interesting, are the two slots on the board.  These are designed to enable me to snap the board into two pieces (see the top of the photo).  The piece on the left is the Joystick interface and Bluetooth (BT) module.  The piece on the right is the matching bluetooth (BT) module that will plug onto the header strip on the hoverboard motor controller.  You also can't tell from the photo, but there is a battery holder on the back of the larger board, that holds two AAA batteries.  You can see the large rectangle outline on the top silk screen.

    The part of this design that I'm most proud of is the way that the two bluetooth modules are set up to automatically pair with each other.  The HM-11 bluetooth modules can be configured using "AT" commands, which is a command style invented with the first analog MODEMS back in the late seventy's, but has been adopted by serial bluetooth modules.

    Each module has a unique address (like a MAC address), and if you know one BT module's address, you can configure another BT module to connect to it on startup.  The trick is reading each module's address and assigning the matching module to connect to it.  This can be done manually with a serial terminal, but the BluJoy program has a dedicated setup mode to do this automatically.  If you look at the reverse side of the board, you will see that there are some power and data traces that pass between the two sides.  

    Each board will come from the manufacturer with blank HM-11 BT modules installed.  To set up the boards, the BluJoy.X program is loaded, and then the two buttons are pressed and held for 4 seconds.  This will trigger the pairing mode where the PIC processor will read each BT module's address, and then configure the opposite module to connect to that address.  The program also sets each BT module's baud rate, Master/Slave relationship and any other parameters.  The code then sends "HELLO" messages into the Slave module on the Joystick side, and verifies that they are received on the Hoverboard side.

    Once the setup and verification is complete, the board can be snapped in two, ready for installation in a hoverboard and joystick.

    This module uses a PIC16LF18446 microprocessor which I chose because it had some key features I required, plus is was available in a relatively small 20 pin SOP package.  In particular, it's the smallest PIC processor with a serial USART (for talking to a BT module) and and EEPROM for storing non- volatile parameters, type of joystick and speed ranges.

    Although the PIC16LF18446 only has one serial port, it also has a PPS (Peripheral Pin Select module) which lets you dynamically switch I/O functions between different pins on the chip.  This let me switch the Serial RX and TX pins between the two BT modules to read and write different parameters.  This was the first time I used a PIC PPS module, and now that I have seen what it can do I don't think I'll ever use a PIC processor that doesn't have one.  

    As an example of how useful the PPS is, in my first PCB I got my RX and TX pins confused when routing between the PIC and BT modules. ...

    Read more »

  • Log #11 DIY Mobility Device.

    Phil Malone07/30/2020 at 20:12 0 comments

    Starting in Log #7, I detailed the process of using my hacked hoverboard to add a power drive to a commercial "Stander".

    In this log, I want to shift to the other end of the spectrum: a complete DIY Mobility device, based on the same Hoverboard Hack.   I'm trying to develop ideas that can be implemented without a large outlay of cash, so this one is based on hardware that the family of the impaired child should already have:  An automotive car seat.

    My idea was to build a simple frame that would allow a car seat to be mounted to a hover-board, and add a caster to provide a third balance point.  I would use small cargo straps to attaching the hover-board to the frame and the seat, so it would just take a bit of creativity to adapt to a specific seat.

    I'm still working on my bluetooth joystick design, so I tested out my prototype HoverChair with my Prototype BluJoy joystick.

  • Log #10 Wireless Control. Take 2

    Phil Malone07/26/2020 at 22:42 0 comments

    My first attempt at adding a wireless remote controller to the Hoverboard wasn't really successful (see Log #5).  Using the ESP32 controller's WiFI capabilities increased the current demand by enough to  overload the Hover-Board's 5V regulator.

    So, for my drive testing, I just switched to a wired joystick.

    However, after some live testing, I really wanted to try wirless again, so I started researching some lower power alternatives.  I ran though a whole range of analog and digital "garage door remote control" style chip sets, but I really couldn't find any I was happy with.

    Then I started researching various Bluetooth serial link modules.  I started with the HC-05 which is a master/slave device that can be used to establish an automatic connection between two serial ports.  This was pretty easy to setup, but it seemed a bit dated.  The next version I discovered was the HM-10 which is newer, and uses less power.  

    To create a Joystick that could be used with either of these devices, I'd need to put some sort of microcontroller in the Joystick, and then have it talk to a serial port on the Hoverboard.  The Hover-Board motor controllers have several serial ports onboard, but I'd been trying to ONLY use the ones that were normally used for Master/Slave communications.  This had required me to add a Micro-Controller inside the Hover-Board case, and have it plug into each of the motor controller boards.  In this way, both controllers were acting as "SLAVES".

    After much soul searching, I decided to abandon this approach, and use one of the "debug" serial ports on the Master Motor Controller.  This mean that I could go back to using a single flipped cable to connect between the Master and Slave controllers.  My HUGS protocol was still compatible with  passing commands between the two controllers, and I could ALSO use it to pass commands from the Joystick to the Master controller.

    This new approach has some key benefits:

    1) I could remove most of the extra wiring I had added to the Hover-Board.  This would make it easier for other hackers to replicate my setup.

    2) The only electronics that needed to be added to the Hover-Board was an HC-05 Bluetooth module which could be connected directly to the REMOTE port on the Master Motor Controller board.  This reduced the 5V power load to only 8mA

    The downsides to this approach were:

    1) I had to solder a set of header pins to the Master Motor Controller board.  This was easy enough for me, but it does require some decent tools and some reasonable skill.  I had been trying to avoid anyone else having to mod the controller boards because they use high voltage and current, so bad soldering can be disastrous.  

    2) The joystick also now needs a HC-05 module, PIC (or other) processor and a battery that needs to be managed to get a reasonable run life.  I did some testing with a Blink-Master board I had on hand.  It gave me a convenient way to try out some PIC code with the HM-10 carrier board.

    My plan is now to produce a custom PCB that can be used for the Joystick, with a snap-off segment that forms a smaller PCB to be used inside the Hover-Board.  Instead of using the full sized module on it's carrier, I'll probably just use the minimal surface-mount module.  Here is the HM-10 and it's little brother, the HM-11.  Note: Those are 1/4" grid squares they are sitting on.

    I'll open-source the PIC software and protocol so anyone can create their own joystick/controller using a pic, arduino or other smart controller.  You could even use a Raspberry PI, and do image processing for a visual controller.

  • Log #9 BLDC Hybrid drive with "2-speed Shifter"

    Phil Malone07/22/2020 at 19:25 0 comments

    While I was experimenting with controlling the speed of the H/B drive wheels, I realized that really slow speed control was difficult to achieve with reasonable torque.  This is unfortunate, because I'm anticipating needing slow (safe) speeds, but I still want to be able to drag a heavy device and child around.

    The mainstream control method is to look at the hall effect sensors to determine the current phase, and then drive the desired (next) phase with a PWM signal.  The duty cycle of the PWM signal controls the "strength" of the rotational torque which effects the speed of rotation.  So to get a very slow speed, the PWM duty cycle must be very low, and then so is the torque.

    I started researching other brushless drive strategies, and came across several articled that described how to run a BLDC (Brush Less DC) motor like a stepper motor.  Anyone who has used a stepper motor knows that the torque is very high, and you can move them slowly, but they are very "cog-y".

    The speed of a stepper motor is set by manually stepping the drive phases through their sequence at the desired rate.  This essentially ignores the normal system of letting the motor free-run, and holds each step for the desired duration.

    Since you are effectively holding the motor in stall, you do need to worry about heating.  But you can still use the PWM to vary the amount of current/torque available.  Unfortunately, this type of drive strategy produces a very noisy and "shaky" wheel motion.  This is because the hoverboard wheel is divided into 90 "steps", so each phase jump corresponds to about 1/4" of forward motion.  

    I finally came upon a more elegant way to run the motors in Stepper Mode.  If you have the processing power available, you can switch from square waves to sine waves for driving the phase coils.  Technically this is called micro-stepping.  

    In this mode, instead of jumping from one phase to the next, the wheel does a smooth transfer (in micro steps).  It's not perfect, but it's much quieter.  I also discovered that instead of using a pure sinusoid, you can use a different curve (called a constant power curve) which is apparently smoother.  I tried both methods and eventually decided on the constant power curve.  To implement this, I used a spreadsheet to determine the curve values, and then I coded them as a lookup table with 1 degree steps.  Since my PWM values go from 0-1000 that's how I scaled the table, but eventually I decided to scale these values down to 1/8th of this to limit self-heating of the motor.

    Having discovered and implemented this new drive strategy, I ran some tests.  I discovered:

    1) I could accelerate very slowly a stop to a preset velocity with a substantial amount of torque.

    2) Rather than using a pure sinusoid, there is a modified "constant power" cure that can provide a smoother motion.

    3) If you are not careful you can overheat the wheel (and probably the drive FETs) if you don't scale down the overall voltage when applying the drive curve.

    4) Once the rotational speed reaches a certain point (about 5% of full speed for me) the motor will start to jump and skip steps if it's put under load.  I suspect this is because I'm not able to run through the Sine wave power curve fast enough.

    So, I had a dilemma.  The classic drive method works great for high speeds but lousy at slow speeds, and the new stepper method is great for slow speeds but lousy at high speeds.  

    My solution was to create a hybrid mode that switches between the two drive methods at a certain drive speed.  The chosen "shifting" speed is the top speed that the stepper method works well.   The final implementation of this strategy can be found in my hoverboard repo.  Check out the bldc.c code.

    My code can run the drive in several modes:

    0) Open loop constant power (traditional)

    1) Closed loop...

    Read more »

  • Log #8 Mechanical Interface. 2nd Gen.

    Phil Malone04/18/2020 at 13:10 0 comments

    In Log #7 I showed my first attempt at pairing the hoverboard with the Jenx Stander.

    It was OK, but not optimal.  I really wanted to find a method that still used the Caster mounts, but one that provided a better turning radius, was very robust, and did not require major mods to the hoverboard itself.  This meant I had to disassemble the hoverboard and really look at it's internal structure.  I wanted to find a way to design an external mounting plate that could be attached to the hoverboard using existing mounting holes, surfaces etc.

    The HOVER-1 ULTRA uses a very strong cast aluminum frame with plastic clamshell covers to shield the electronics.  (See this gallery pic).  What was interesting is that there are opening in the aluminum underneath the electronics to allow the "foot detect" switch actuators pass through.  These are beam-break sensors on the bottom of the PCB that are actuated by rubber mounted pressure plates on the outside of the hoverboard.  After completely disassembling the hoverboard I could investigate my options.`

    The underside is on the left, and the topside is on the right.

    The one thing I was most concerned with, when designing the mounting method, was keeping the attach-point as close as possible to the wheels.  The further away these two points were, the greater the buckling force would be on the board and the mounting plate.  Greater forces mean heavier plates and bigger bolts etc.  

    In the end I think I came up with a clever solution.  I would form a hoverboard "sandwich" by placing a small aluminum plate on either side of the board, and tie them together with bolts that went through the large openings.  I would use an oversized bolt, which would also form the mounting point.  The "bread" plates on the underside of the board would actually be small disks that bolted to the chassis using the holes that were used to hold the rubber beam breakers in place.  On the topside I would use a single plate, with two matching holes, that fit snugly inside a depression in the casting.

    Each side of the hoverboard only really needed one mounting point, so the other bolt was just used to firmly anchor the top plate in place, and help spread the load.  The bolt that is going to be a mounting point is attached to it's disk with a locknut, so once it's screwed in place it won't move. The other shorter bolt was inserted through the top plate and just attached to the mounted disk with a nut.  

    Note: My plan is to change this method by adding captive rivet nuts to the disks so all the bolts are just inserted from the top once everything is assembled.

    I made my first prototypes by hand, but getting the hole spacing and location correct was a pain.  Since I knew I would need more I did a quick CAD design and order a few sets from  You should never discount the time it takes to make a part, and the benefit gained from paying a service to fab it accurately for you.

    Since the resulting bolt spacing did not match the caster wheel spacing, I had to remove the connecting pivot bar from between the two hoverboard halves.  This was actually the most difficult mechanical part of the project, because the ring-clips used to hold the bar in place was a PAIN to get off.  I then mounted the two halves to the frame to see how strong everything was.  Since the caster mounting holes were inside 1" steel tubes, when everything was bolted together, the resulting structure was immensely strong.  With the 3/8" bolt snugged (not cranked) down there was absolutely no wobble or deflection when I placed a load on the Stander.

    The only issue was that I could rotate the hoverboard due to it's single point of attachment.  So I decided I just needed to replace the central pivot tube with something else to keep the two sides aligned.  This posed a bit of a problem since...

    Read more »

  • Log #7 Mechanical Interface. 1st Gen.

    Phil Malone04/17/2020 at 23:47 0 comments

    In Log #6 I showed how I had gotten the Hoverboard driving, but now I had to consider how I was going to mechanically link it with specific assistive platforms.

    When I contacted a local Occupational Therapist, she showed me two "Standers" that were used by her children clients.  These were marvelous mechanical structures designed to support a child with limited, or no muscular strength or stability (my non-medical description).  

    The two specific devices I reviewed were the Jenx Multi-Stander and the Jenx Standz: Abduction stander.  The smaller Multi-Stander is shown below in green, and the larger Abduction stander is shown in yellow.

    I had initially thought I would be trying to add a power drive to a lower cost plastic structure, like a toy ride-in car, but these much heavier structures posed a different challenge.

    With a cheap toy, there would be no issues making major mechanical mods to incorporate the Hoverboard drive, but these medical devices range in price from $2-5K so any addition of an external power drive needs to be non invasive. Translation: no drilling holes or bending parts.

    The good news was that in both cases the casters are removable with a socket wrench, and so I decided to look for ways to use the existing caster mount-points to attached to the hoverboard.  The smaller Multi-Stander was available for me to "play with" so I decided to make this my test case.

    The tubular caster supports each has a 3/8" hole so as long as I could use a 3/8" bolt, I was golden.

    My first approach was to make brackets that could bolt to the Stander (in place of the casters), and then clip on top of the hoverboard (fitting around the wheel guards).   Since the hoverboard was too wide to fit inside the caster mounts, it would need to be slung out further back/forward than the casters.  This would impose a considerable torque on any mount.  I made some aluminum brackets out of 1/8" thick L-channel.  I used the L shape to prevent bending.

    The brackets worked reasonably well, but they had some issues:

    I was hoping that the weight of the Stander resting on the brackets would anchor them to the hoverboard, but this wasn't the case.  The rotational torque of the drive when trying to spin the Stander was quite large, and so the hoverboard would lift up and try to spin.  As a temporary fix, I used Gorilla Tape to hold the brackets to the hoverboard.

    The other issues was that the Stander tended to rotate around the center of the hoverboard, and this caused it to traverse a very wide arc.  This made it difficult to navigate in tight spaces.  

    Ideally, I wanted to move the drive closer to the center of the Standar, without obstructing any of the mechanisms.

  • Log #6 Motion Control

    Phil Malone04/17/2020 at 20:52 0 comments

    In Log #5 I discussed wireless vs wired control input, and eventually decided on a simpler wired input system.

    I have now assembled all the mechanical and electrical components to produce a working Joystick controlled hoverboard.  Next I needed to decide on an initial motion control strategy.

    My first concern was that if a fragile child would be directing the drive system, the resulting motions needed to gentle yet responsive.  My first thoughts were that I needed to control acceleration and deceleration, more so than just speed or power.  I also felt that the drive needed to stop more quickly than it started simply to prevent running into things.

    My initial code established a strategy for applying an acceleration limit, based on target speed and elapsed cycle time.  I tweaked this strategy to allow for a larger acceleration when starting movement than for stopping (eg, if the desired speed was zero, then a larger acceleration limit would be applied).

    I then chose different speed and acceleration constants for the axial (fwd/rev) and yaw (left and right) motions.

    Needless to say I did a lot of testing with my "make-shift" adaptive platform to get my best "initial" values.

    As I was experimenting with the drive, I realized that the final version was probably going to need to be a lot slower, so I would be using a pretty small portion of the full speed range.  From my experience with youth robotics teams I know that once you start dropping the voltage on motors using Pulse Width Modulation (PWM), you also reduce the torque available to the motor to overcome things like friction and inertia.  So starting to move from a stopped position smoothly can be tough.

    So I decided to implement closed loop control for the motor drive.  This essentially means that instead of requesting a certain Power for the drive, you are actually requesting a speed (or velocity if you consider moving forward and backwards).  Then, it's up to the controller to measure the speed, compare it with the requested speed, and then automatically adjust the power to make the actual match the requested.  Thus the control loop is "Closed" using feedback.

    I had already implemented speed measurement in the hoverboard code, but I stepped it up a notch by counting individual phase steps, rather than full phases.  This gave me 90 "encoder" counts per revolution.  

    I then implemented a simple Proportional controller with Feed-Forward added.  Testing showed that this method ensures that even if I only ask for 1% speed,  I get a solid motion.

    I was finally ready to try adding the Hoverboard to a REAL assistive device.  The challenge was now going to be combining two mechanical systems that were never meant to be combined.

  • Log #5 Going Wireless

    Phil Malone04/17/2020 at 19:28 0 comments

    In Log #4 I described the process of getting the HUGS protocol running on the hoverboard.  Once I had that under control I needed to think about what my first Human Machine Interface (HMI) was going to look like.

    My first test platform was going to be a Jenx Multi-Stander, which is basically a complex collection of framework and padding on wheels, designed to provide support and mobility to a young child with minimal muscle strength or control.

    I considered different input options, and finally decided on an arcade joystick with limit switches.  I chose this in lieu of an analog joystick because a child with reduced fine motor control will not gain much benefit from a proportional controller, and a switch based joystick will be very robust.  My ultimate goal is to generate some smart motion profiling based on observed control behavior.

    The next question to resolve was should the input device be wired to the hoverboard, or should it be wireless.  

    Since we live in a wireless world, so I thought I'd run down this road until I hit a roadblock.

    The ESP32 supports WiFi and Bluetooth.  Bluetooth is cool for low power devices, but once I started looking at the software required to get point-point working, I was a bit discouraged.  Then I discovered that Espressif (make of the ESP family) has a pre-built WiFi protocol for interconnecting their chips.  

    It's called ESPNow, and there is a sample project in the IDF to show how it works.  I implemented espnow on two ESP32 dev kits, to see how well I could transmit joystick information wirelessly.  The implementation went pretty well, but I ran into other problems.   

    So far I had been using the 5V supply that the motor controller board was providing to run my embedded HMI processor.  This power was convenient because it was one of the pins on the UART cable.  Unfortunately whenever the ESP32 started using WiFi, this supply got squirrely (a very technical term).  It seems that the ESP was pulling too much current to be supplied from a single motor controller.  As long as both of them were powered up, everything worked fine, but during startup or shutdown when only one might be providing power, the ESP got erratic and it would not always recover...  This left the hoverboard in a bad state where it would not power up or down properly.

    So, in the end I decided that I didn't need wireless that badly, and I decided to go down the tethered joystick road.   Although I did not end up using espnow, if you want to see how it works, there is a espnow branch in my ESP HUGS repository.

    Ultimately I prefer the tethered approach.  This way there are no "pairing" issues or loss of control due to interference or low batteries.... and no batteries.  You also can't lose the joystick because it's connected.  I was able to pull the power switch out of the hoverboard case, and replace it with a rubber grommet that protected the robust 6 conductor cable that I ordered.

    I also decided on a smaller switch-based joystick.  I mounted it in a small plastic box, along with the relocated on/off switch.  Now I finally had all the controls I needed.  Next up is refining the motion controls.

  • Log #4 Developing HUGS

    Phil Malone04/17/2020 at 15:04 0 comments

    HUGS is an acronym. It stands for: Hoverboard Utility Gateway System. Yes, it's a bit contrived, but every project needs at least one cute acronym :)

    The idea was (and still is) to modify the Hoverboard firmware, to provide a standard control interface, and provide the opportunity for hobbyists with mid-level tools and skills to use the boards for a variety of drive purposes.  I want to keep as much of the standard hoverboard electronics and hardware untouched (or at least un-modified) and then use existing connectors etc. to provide an external control interface.  This interface would be used to receive commands from, and send system status back to, a control processor.

    The HOVER-1 ULTRA boards have one serial interface that connects the left and right side motor controllers, and so I decided to repurpose this interface for external commands.  There are several other serial ports available on the controller boards, but these are exposed as sets of PCB pads that  don't have anything connected to them.  These can be used as additional ports, but you need to solder header pins to them, and frankly, it's tricky, even for an experiences builder. 

    It IS possible to reprogram the motor controllers without actually soldering pins to the board, just by pressing the programming header onto the pads, so that was consistent with my goal of not requiring electrical modifications.

    So, I started out by creating what I thought would be an efficient control-protocol specification.  I wanted to be able to control the speed and position of the drive wheels, as well as being able to enable and disable the controller and get feedback on things like speed, position, voltage, current etc.

    I chose a binary packet format (rather than ASCII Text) in order to keep the packets short (and fast).  Each variable length packet would contain start and end bytes, variable length data and a checksum.  Each incoming command would also request a specific response packet containing sensor or status data.   The HUGS protocol would run at 115200 BAUD.

    I've included the Protocol Specification in my files list.

    When I went to start implementing the HUGS protocol in my deployment test code, I realized that there were a lot of elements in the Lawn Mower code that I didn't need.  So to simplify things, I forked a new repository from the original Florian Gen 2 code base.  This became the basis for my Hoverboard_Utility_Gateway_System repository.

    Whenever you develop a protocol, you typically need something to run at both ends to test that it works.  In my case my initial plan was to embed an ESP32 based processor into the hoverboard chassis to act as a "Human-Machine Interface" (HMI), so it made sense for me to work on this component simultaneously with the hoverboard firmware. 

    I grabbed an ESP32 DevKit 1 prototyping module and plugged it into a proto-board and then added some cable headers that matched the cable already being used by the Hoverboard.  Instead of a single cable running between the Master and Slave controllers, I needed to run a separate cable from each controller, so my prototype board had both a master and slave connecter.

    The ESP32 it really small and capable with WiFi and Bluetooth, but the reason I chose it over it's little brother (the ESP8266) is that is comes with three UARTs in hardware.  One of these is usually dedicated to the download/diagnostics function, which leaves two that can be used to talk to the two motor controllers.  You can access these three ports easily with the ESP32-IDE, and with a bit of fiddling with the Arduino IDE.  I had just done a major project wit the ESP32-IDF so I used that.

    The first HUGS command that I implemented was the SetPower command which just translated into PWM power values of +/- 1000 in the bldc.c code.  The new hoverboard firmware accepted the command from the HMI and then...

    Read more »

View all 13 project logs

Enjoy this project?



crispind wrote 09/02/2020 at 19:50 point

Impressive work,
Regarding your joystick; I have used my phone together with the Dabble app and successfully managed to control a motorised stroller (equipped with a hoverboard and ESP32 wroom). This was fairly easy implemented since there’s an Arduino library specially for the ESP32 board (

I had to modify the library slightly though since I couldn’t find a built in command that would stop the stroller if the connection was lost...

No need for extra peripheral hardware which simplified the setup for me at least.


  Are you sure? yes | no

Phil Malone wrote 5 days ago point

Thanks for the info.  Yes, stopping on a lost connection is pretty essential :)  

  Are you sure? yes | no

Phil Malone wrote 08/14/2020 at 16:35 point

I've just updated my Github Repository link to point to a new "all in one" repo for this project.

This repo. includes the Hoverboard firmware,  Bluetooth joystick code & PCB design as well as CAD files.

  Are you sure? yes | no

William Jacoby wrote 08/12/2020 at 03:56 point

From a wheel chair users perspective this is definitely interesting. Is it simple to up the speed.

  Are you sure? yes | no

Phil Malone wrote 08/14/2020 at 15:54 point

Yes.  I'm having to work hard to get good performance at super-slow speeds for a child's unit.  Going fast is much easier.  My current design strategy is that the actual speed range is set IN the controller that's attached to the Joystick.  The Hoverboard itself will accept speeds up to 5 meters per second (darn fast).  My latest Joystick controller will have several selectable speed ranges, with associated trapezoid (smooth) speed profiles.  Buttons on the board can be used to set the speed ranges, and these settings are remembered.   I'm updating my online repo to include the new joystick controller (called BluJoy).  

  Are you sure? yes | no

John Opsahl wrote 07/27/2020 at 02:15 point

I always learn at least one new thing when reading your project logs. Thanks for sharing. After the hacks, do you expect the typical 3 to 4 hours of operarion between battery charges? 

  Are you sure? yes | no

Phil Malone wrote 07/27/2020 at 12:13 point

Thanks, I'll keep adding as much detail as I can on each log... I have a few more pending.  I keep focussing in on the HOVER-1 ULTRA as my platform of choice, and it has a decent 4AH, 36V battery, so it's good for a long haul.  I can't imagine these devices being used for long continuous runs (like a typical hoverboard) so it's hard to predict time between charges.  I suspect most use would be stop and go, with periods of nothing in between. I've maintained the automatic power down logic to minimize unnecessary discharge.  When it's on and idle, the unit pulls about 150mA, so that would set an upper battery limit of about a day if it was kept alive with minimal movement.  Once my PT contact can get back to working with kids, I'll get to do some real tests on battery usage.

  Are you sure? yes | no

Harsh wrote 06/17/2020 at 15:31 point

Hello Phil,

I was wondering if you could provide the schematic diagram of the connections of the ESP module along with the code used for it.

  Are you sure? yes | no

Phil Malone wrote 07/22/2020 at 19:12 point

The ESP32 code is located in the HUGs Github repo that's lined as a resource for this project:  I have a prototype schematic to go with it, but I've hacked it a bit since then.  I'll add it to the resource list.

  Are you sure? yes | no

Phil Malone wrote 04/16/2020 at 13:02 point

I'm in early prototyping mode.  I've only just started adding this project to Hackaday so it's slow going as I figure out the process.  The project is way ahead of what's currently shown here.  It will take a few days to get logs online in some reasonable form.  If you click on my "Hoverboard Firmware" link it will take you to my GITHUB repo.  Then, click on the number next to the "FORK" box at the top of the page, and it will show you the original repo that I forked from.

  Are you sure? yes | no

KenSamson wrote 04/16/2020 at 02:15 point

Is this still active?    Would you share your code, and point to the github that you found?

  Are you sure? yes | no

Phil Malone wrote 07/22/2020 at 19:13 point

My code, and the repo that I based it on are linked in Log #2.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates