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 responded with the requested status data.
The code for the ESP32 was setup to read a potentiometer and convert the value into power values and send this to the Hoverboard. This way I could get a feel for the performance of the hoverboard code and drive electronics simply be twiddling the pot. I implemented ALL the different response codes, so the ESP was able to sequence through them and display the replies on a serial terminal on the PC, as part of the ESP32-IDF console.
I learned some interesting things while doing this initial testing. Each of the motor controller boards are capable of shutting down their own 5.0V Power supply, but only the board that is connected to the power button can see the request for power on or off. It must pass this information across to the other side via the serial port, so the HUGS interface has to be able to report a "power off" request up to the HMI so it could relay it to the other controller. The obvious question then is how does the other side get turned on? It turns out that the 5V supply form each controller is shared across the serial interface, so if either controller power up, it powers up the opposite side. Thus BOTH sides must hold the power OFF for the electronics to be truly turned off.
After I had proven that I could run the board from an ESP32 with no problems, I built a wired protype HMI board (vs the solderless proto-board) to make my testing a little less likely to fall apart. At the same time I started a PCB design to send off to PCBway.com
Here are the resulting schematic and board layout.
Note that the board has two connectors for attaching to the slave, and two for the master. The two pairs of connectors just have their TX and RX pins swapped. This is to accommodate the type of cable you are using (crossover or straight through). Ultimately the TX line from the ESP32, needs to get paired with the RX line of the Hoverboard controller.
Next, lets think about wireless control.