- updated ReadMe: added higher resolution mainboard picture, added links with projects, online compiler, Telegram link
- setup.c : fixed the Charger GPIO pin to PULLUP, otherwise the Charger won't be recognized when connected
- config.h : increased the default ADC protection Timeout from 30 to 100 for more robustness.
The original Hardware supports two 4-pin cables that originally were connected to the two sensor boards. They break out GND, 12/15V and USART2&3 of the Hoverboard mainboard.
Both USART2 & 3 can be used for UART and I2C, PA2&3 can be used as 12bit ADCs.
- **VOLTAGE MODE**: in this mode the controller applies a constant Voltage to the motors
@ -36,7 +36,7 @@ In all the modes, the controller features maximum motor speed and maximum motor
- The C code for the controller was auto-code generated using [Matlab/Simulink](https://nl.mathworks.com/solutions/embedded-code-generation.html) from a model which I developed from scratch specifically for hoverboard control. For more details regarding the working principle of the controller please consult the [Matlab/Simulink model](/01_Matlab).
- A [webview](/01_Matlab/BLDC_controller_ert_rtw/html/webview) was created, so Matlab/Simulink installation is not needed, unless you want to regenerate the code. The webview is an html page that can be opened with browsers like: Microsoft Internet Explorer or Microsoft Edge.
### Firmware architecture
### Firmware Architecture
The main firmware architecture includes:
- **Estimations**: estimates the rotor position, angle and motor speed based on Hall sensors signal
@ -86,7 +86,9 @@ Each motor is constantly monitored for errors. These errors are:
The error codes above are reported for each motor in the variables **rtY_Left.z_errCode** and **rtY_Right.z_errCode** for Left motor (long wired motor) and Right motor (short wired motor), respectively. In case of error, the motor power is reduced to 0, while an audible (fast beep) can be heard to notify the user.
@ -107,7 +107,7 @@ This firmware offers currently these variants (selectable in [platformio.ini](/p
- **VARIANT_PPM**: This is when you want to use an RC remote control with PPM Sum signal.
- **VARIANT_PWM**: This is when you want to use an RC remote control with PWM signal.
- **VARIANT_IBUS**: This is when you want to use an RC remote control with Flysky IBUS protocol connected to the Left sensor cable.
- **VARIANT_HOVERCAR**: In this variant the motors are controlled by two pedals brake and throttle. Reverse is engaged by double tapping on the brake pedal at standstill.
- **VARIANT_HOVERCAR**: In this variant the motors are controlled by two pedals brake and throttle. Reverse is engaged by double tapping on the brake pedal at standstill. See [HOVERCAR video](https://www.youtube.com/watch?v=IgHCcj0NgWQ&t=).
- **VARIANT_HOVERBOARD**: In this variant the mainboard reads the sideboards data. The sideboards need to be flashed with the hacked version. Only balancing controller is still to be implemented.
- **VARIANT_TRANSPOTTER**: This build is for transpotter which is a hoverboard based transportation system. For more details on how to build it check [here](https://github.com/NiklasFauth/hoverboard-firmware-hack/wiki/Build-Instruction:-TranspOtter) and [here](https://hackaday.io/project/161891-transpotter-ng).
@ -148,7 +148,7 @@ make
```
or you can set the variant like this
```
make -e VARIANT=VARIANT_NUNCHUK
make -e VARIANT=VARIANT_####
```
- flash the firmware by typing:
```
@ -212,14 +212,25 @@ Most robust way for input is to use the ADC and potis. It works well even on 1m
- Github: all the people that contributed via Pull Requests
- ST Employee: [cedric H](https://community.st.com/s/question/0D50X0000B28qTDSQY/custom-foc-control-current-measurement-dma-timer-interrupt-needs-review)
EmanuelFeru
6 years ago
