search

chrisstubbs93 / hoverboard-firmware-hack-FOC

With Field Oriented Control (FOC)
GNU General Public License v3.0
1 stars 0 forks source link

readme

roamerFW

Hoverboard firmware for EMF roamer Forked from the brilliant work at hoverboard-firmware-hack-FOC Python script based on this

Build instructions

Use linux (ubuntu) subsystem for windows

cd /mnt/c/Users/Chris/Documents/GitHub/hoverboard-firmware-hack-FOC
make

OR Use VScode

Install "makefile tools" plugin by Microsoft
In powershell "choco install make"
Install Arm GNU Toolchain "Windows (mingw-w64-i686) hosted cross toolchains AArch32 bare-metal target (arm-none-eabi)" whatever that means.

Build via makefile tools plugin on LHS of VScode

flash .bin with ST-LINK while holding HB power button

General roamer notes:

Input range ovser serial is -1000 to 1000 Set up front hoverboard with 

#define I_MOT_MAX       8
#define I_DC_MAX        10

Set up rear hoverboard with 

#define I_MOT_MAX       25
#define I_DC_MAX        27

A little spin on the garage floor. Probably a good balance for road/grass.

Raced Scrumpy cup 23/25 rear, 8/10 front (i think). No fuse pops but did burn out rear motor and controller.

Propose shifting power forward and increasing overall a little. 21/23 rear, 15/17 front popped fuse racing tarmac trying 20/22 rear, 13/15 front popped trying 19/21 , 11/13 front

Did pop a couple of fuses at makers 24

Try fuse modelling tests at 21/23 / 16/18 (think this is the current cybrtrk config) Proposed 12/14, 12/14, 6/8 for volt-crane-o. no pops at emf going for 15/17 on both rears. Did eventually pop on long hill.

Fuse popped on cybertruck at footfest 24. dialing down to 19/21 on rear. Reducedd to 17/19. reduced to 15/17. Root cause likely arduino PID disabled!

16/09/24 setting CYBRTRK up for 21/23 rear, 10/12 front. This should peak at 70A.

Crane popped a couple of fuses at scrumpy 24 at (i think) 12/14, 12/14, 6/8. Current meter showed 30A exactly though? Reducing to 10/12 rears. Driving in to stall is ~13 amps on clamp meter, but full speed on track was 40a with same settings. Trying disabling field weakening, same. Trying 2x amps not 2+ amps, no difference. After getting home, with the same settings, almost 20A driving in to stall.

CYBR TRK fuse monitoring seems to be working well at scrumpy (21/23 rear, 10/12 front)

Fuse monitoring implemented on crane. Was set to target total peak of 70A to match cybrtrk anyway, but performance off the line was lacking? Use same front/rear settings as they seem punchy, but may lead to overshoot in arduino PID loop?. Trying 21/23 rear(s), 10/12 front, FW ON. <- gives <50A!

Current settings: CYBR TRK 21/23 rear, 10/12 front, FW ON CRANE 21/23 rear(s), 10/12 front, FW ON

#define INVERT_R_DIRECTION and #define INVERT_L_DIRECTION because I put all the motors on backwards lol

hoverboard-firmware-hack-FOC

Build Status License: GPL v3 paypal

This repository implements Field Oriented Control (FOC) for stock hoverboards. Compared to the commutation method, this new FOC control method offers superior performance featuring:

Table of Contents

For the hoverboard sideboard firmware, see the following repositories:

For the FOC controller design, see the following repository:

Videos:

Hardware

mainboard_pinout

The original Hardware supports two 4-pin cables that originally were connected to the two sideboards. They break out GND, 12/15V and USART2&3 of the Hoverboard mainboard. Both USART2&3 support UART, PWM, PPM, and iBUS input. Additionally, the USART2 can be used as 12bit ADC, while USART3 can be used for I2C. Note that while USART3 (right sideboard cable) is 5V tolerant, USART2 (left sideboard cable) is not 5V tolerant.

Typically, the mainboard brain is an STM32F103RCT6, however some mainboards feature a GD32F103RCT6 which is also supported by this firmware.

For the reverse-engineered schematics of the mainboard, see 20150722_hoverboard_sch.pdf

FOC Firmware

In this firmware 3 control types are available:

Comparison between different control methods

Control method Complexity Efficiency Smoothness Field Weakening Freewheeling Standstill hold
Commutation - - ++ n.a. n.a. +
Sinusoidal + ++ ++ +++ n.a. +
FOC VOLTAGE ++ +++ ++ ++ n.a. +(2)
FOC SPEED +++ +++ + ++ n.a. +++
FOC TORQUE +++ +++ +++ ++ +++(1) n.a(2)

(1) By enabling ELECTRIC_BRAKE_ENABLE in config.h, the freewheeling amount can be adjusted using the ELECTRIC_BRAKE_MAX parameter.
(2) The standstill hold functionality can be forced by enabling STANDSTILL_HOLD_ENABLE in config.h.

In all FOC control modes, the controller features maximum motor speed and maximum motor current protection. This brings great advantages to fulfil the needs of many robotic applications while maintaining safe operation.

Field Weakening / Phase Advance

Parameters

Example Variants

This firmware offers currently these variants (selectable in platformio.ini or config.h):

Of course the firmware can be further customized for other needs or projects.

Dual Inputs

The firmware supports the input to be provided from two different sources connected to the Left and Right cable, respectively. To enable dual-inputs functionality uncomment #define DUAL_INPUTS in config.h for the respective variant. Various dual-inputs combinations can be realized as illustrated in the following table: Left Right Availability
ADC(0) UART(1) VARIANT_ADC
ADC(0) {PPM,PWM,iBUS}(1) VARIANT_{PPM,PWM,IBUS}
ADC(0) Sideboard(1*) VARIANT_HOVERCAR
UART(0) Sideboard(1*) VARIANT_UART
UART(1) Nunchuk(0) VARIANT_NUNCHUK

(0) Primary input: this input is used when the Auxilliary input is not available or not connected.
(1) Auxilliary input: this inputs is used when connected or enabled by a switch(*). If the Auxilliary input is disconnected, the firmware will automatically switch to the Primary input. Timeout is reported only on the Primary input.

With slight modifications in config.h, other dual-inputs combinations can be realized as: Left Right Possibility
Sideboard(1*) UART(0) VARIANT_UART
UART(0) {PPM,PWM,iBUS}(1) VARIANT_{PPM,PWM,IBUS}
{PPM,PWM,iBUS}(1) Nunchuk(0) VARIANT_{PPM,PWM,IBUS}

Flashing

Right to the STM32, there is a debugging header with GND, 3V3, SWDIO and SWCLK. Connect GND, SWDIO and SWCLK to your SWD programmer, like the ST-Link found on many STM devboards.

If you have never flashed your sideboard before, the MCU is probably locked. To unlock the flash, check-out the wiki page How to Unlock MCU flash.

Do not power the mainboard from the 3.3V of your programmer! This has already killed multiple mainboards.

Make sure you hold the powerbutton or connect a jumper to the power button pins while flashing the firmware, as the STM might release the power latch and switches itself off during flashing. Battery > 36V have to be connected while flashing.

To build and flash choose one of the following methods:

Method 1: Using Platformio IDE

Method 2: Using Keil uVision

Method 3: Using Linux CLI

Method 4: MacOS CLI

Using Make

brew install stlink

Using platformio CLI

brew install platformio
platformio run -e VARIANT_####
platformio run –target upload -e VARIANT_####

If you have set default_envs in platformio.ini you can ommit -e parameter

Troubleshooting

First, check that power is connected and voltage is >36V while flashing. If the board draws more than 100mA in idle, it's probably broken.

If the motors do something, but don't rotate smooth and quietly, try to use an alternative phase mapping. Usually, color-correct mapping (blue to blue, green to green, yellow to yellow) works fine. However, some hoverboards have a different layout then others, and this might be the reason your motor isn't spinning.

Nunchuk not working: Use the right one of the 2 types of nunchuks. Use i2c pullups.

Nunchuk or PPM working bad: The i2c bus and PPM signal are very sensitive to emv distortions of the motor controller. They get stronger the faster you are. Keep cables short, use shielded cable, use ferrits, stabilize voltage in nunchuk or reviever, add i2c pullups. To many errors leads to very high accelerations which triggers the protection board within the battery to shut everything down.

Recommendation: Nunchuk Breakout Board https://github.com/Jan--Henrik/hoverboard-breakout

Most robust way for input is to use the ADC and potis. It works well even on 1m unshielded cable. Solder ~100k Ohm resistors between ADC-inputs and gnd directly on the mainboard. Use potis as pullups to 3.3V.

Diagnostics

The errors reported by the board are in the form of audible beeps:

For a more detailed troubleshooting connect an FTDI Serial adapter or a Bluetooth module to the DEBUG_SERIAL cable (Left or Right) and monitor the output data using the Hoverboard Web Serial Control tool developed by Candas.

Projects and Links

Stargazers

Stargazers over time

Contributions

Every contribution to this repository is highly appreciated! Feel free to create pull requests to improve this firmware as ultimately you are going to help everyone.

If you want to donate to keep this firmware updated, please use the link below:

paypal