AFFBWheel with hoverboard wheel

[oiler2016]

Hey.

Is there a possibility for you to make an implementation to make it possible to use the hoverboard wheel together with the hoverboard's controller board? Currently it is commonly used VESC+STM32 or Odrive to control hoverboard motor and use for force feedback. This scheme also requires an incremental encoder and a few more absolute encoder models. The controller board of the hoverboard itself already has an STM32 and all the necessary circuitry. In the hoverboard wheel, in addition to phase 1, phase 2 and phase 3, there is also a hall sensor for each phase. Therefore, it would not be necessary to use another controller besides the original one of the hoverboard itself. Here is a link talking a little about the board of the hoverboard itself:

https://github.com/lucysrausch/hoverboard-firmware-hack

If you can't do this implementation, could you give me some guidance to get started?

Congratulations on your project!

[vsulako]

This will require rewriting everything from scratch.
This project is for ATMega32U4, it will not work on STM32.
And as I see from pinout image, hoverboard controller does not have USB, so I don't think it can be used as gaming controller.

But, may be there is a simpler way.
Unfortunately, I don't have a hoverboard to play with, so I can only suggest.

There is an example of hoverboard control via UART, I2c, analog signal or PPM signal at https://github.com/p-h-a-i-l/hoverboard-firmware-hack
So, with this firmware hoverboard can just receive force value for rotation from separate gaming controller.

UART seems to be most convenient. Atmega32U4 cannot produce true analog signal, PPM or I2c require additional coding.
And luckily, ATmega32U4 has hardware UART, which is unused in AFFBWheel. At Leonardo/ProMicro boards it is placed on pins 0/1 (initially these pins are for encoder, so encoder should be moved to 2/3 pins)
So, UART is simplest to implement.
At hoverboard controller, use UART3 at PB10/PB11 - because these pins are 5v tolerant on STM32F103.

As for software change, all is needed is to rewrite motor.cpp to send rotation commands via UART to hoverboard controller instead of forming PWM signal.
HW UART on Leonardo/ProMicro is addressed as Serial1.
Example of UART code is on hoverboard-firmware-hack page.
I did not understand why there are 2 values - speed and steer. Method is needed to convert FFB force value (-16383..16383) to speed/steer values (-1000...1000), I think it will need some experimenting.

[oiler2016]

This will require rewriting everything from scratch. This project is for ATMega32U4, it will not work on STM32. And as I see from pinout image, hoverboard controller does not have USB, so I don't think it can be used as gaming controller.

But, may be there is a simpler way. Unfortunately, I don't have a hoverboard to play with, so I can only suggest.

There is an example of hoverboard control via UART, I2c, analog signal or PPM signal at https://github.com/p-h-a-i-l/hoverboard-firmware-hack So, with this firmware hoverboard can just receive force value for rotation from separate gaming controller.

UART seems to be most convenient. Atmega32U4 cannot produce true analog signal, PPM or I2c require additional coding. And luckily, ATmega32U4 has hardware UART, which is unused in AFFBWheel. At Leonardo/ProMicro boards it is placed on pins 0/1 (initially these pins are for encoder, so encoder should be moved to 2/3 pins) So, UART is simplest to implement. At hoverboard controller, use UART3 at PB10/PB11 - because these pins are 5v tolerant on STM32F103.

As for software change, all is needed is to rewrite motor.cpp to send rotation commands via UART to hoverboard controller instead of forming PWM signal. HW UART on Leonardo/ProMicro is addressed as Serial1. Example of UART code is on hoverboard-firmware-hack page. I did not understand why there are 2 values - speed and steer. Method is needed to convert FFB force value (-16383..16383) to speed/steer values (-1000...1000), I think it will need some experimenting.

Thanks for the answer!

In fact, in my first question, I didn't want to mention that the whole project should be rewritten. I suggested one extra implementation only.

About the hoverboard firmware asking for steering and speed: there is a way to disable the steering request and that way only the speed is sent, and that's how I'm doing it.

I am trying to do as per your guidance. I adjusted the Encoder for pins 2/3 of the Arduino Leonardo, but I'm having problems mapping from -16383 to 16383 to -1000 to 1000. Debugging through the Arduino serial I see that the mapping only occurs when the wheel is getting close to the extremes. For example:

I configured the wheel at 1080º and when I turn it, getting close to 540º, the mapping starts to be done. Likewise for -540º. And in this scenario (-16383 to 16383 to -1000 to 1000), when reaching the extreme, the wheel spins uncontrolled in the same direction instead of pushing towards the center. But if in the Arduino Leonardo code I put the mapping -16383 to 16383 for 1000 to -1000, then when reaching one of the extremes the wheel makes an effort to return to the center, but it is the only FFB effect that occurs. All others do not appear to be activated.

Debugging directly from the hoverboard board, I also see that the mapping values only activate near the extremes of the wheel.

In the firmware part of the hoverboard board apparently everything is OK with the settings. I tested it with the Arduino code that accompanies the project https://github.com/EFeru/hoverboard-firmware-hack-FOC and it works perfectly.

I'll keep trying to rewrite the motor.cpp, but I think it will take time.

[vsulako]

if in the Arduino Leonardo code I put the mapping -16383 to 16383 for 1000 to -1000, then when reaching one of the extremes the wheel makes an effort to return to the center, but it is the only FFB effect that occurs.

I think you see the work of endstop. It is always on (in fact, it is not an FFB effect at all)
It limits wheel rotation in configured range.
When you turn wheel beyond limits, backward force is produced until wheel returns back to set range.
Obviously, if motor direction is reversed, wheel will endlessly spin in opposite direction, so, reversed mapping -16383..16383 to 1000...-1000 seems to be correct.
Don't expect returning to center, it's the job of Spring effect (to see it in action, you need to explicitly create it)
From your description, I can suggest that endstop is working. Other effects also should work.

All others do not appear to be activated.

How do you test them? In a game, FEdit, or Wheelcheck?

[oiler2016]

if in the Arduino Leonardo code I put the mapping -16383 to 16383 for 1000 to -1000, then when reaching one of the extremes the wheel makes an effort to return to the center, but it is the only FFB effect that occurs.

I think you see the work of endstop. It is always on (in fact, it is not an FFB effect at all) It limits wheel rotation in configured range. When you turn wheel beyond limits, backward force is produced until wheel returns back to set range. Obviously, if motor direction is reversed, wheel will endlessly spin in opposite direction, so, reversed mapping -16383..16383 to 1000...-1000 seems to be correct. Don't expect returning to center, it's the job of Spring effect (to see it in action, you need to explicitly create it) From your description, I can suggest that endstop is working. Other effects also should work.

All others do not appear to be activated.

How do you test them? In a game, FEdit, or Wheelcheck?

I did new tests. I kept the mapping from -16383 to 16383 to 1000 to -1000 and tested it in Euro Truck simulator 2 and Assetto Corsa.

In ETS2 collision effects do not happen. Too many effects are apparently happening, but there is a lack of control in the wheel at times. Watch the video that shows the problem:

HIDE

In Assetto Corsa this same problem occurs and there are also no collision effects and no track effects either.

I tried tests on WheelCheck and the effects enable, but do not disable even selecting the option in the program. See the video please:

HIDE

I just edited the motor.cpp, added the mapping (map function) and inserted the settings and the Send method from the example file: https://github.com/EFeru/hoverboard-firmware-hack-FOC/blob/main/Arduino/hoverserial/hoverserial.ino

In the rewritten motor.cpp, the Send method sends the Steering value zero and the mapped speed via serial: Send(0,mapedForce). I'm using only two wires from the Arduino Leonardo to connect to the hoverboard's motherboard: GND and TX (connected to the motherboard's RX).

In the videos you can see a noise that I believe is from the power supply. Later I will get a stronger source.

I am confident that your project can become the solution for hoverboard motherboard use in force feedback projects.

[vsulako]

Second video with wheel not stopping makes me think it is a communication issue.
May be, arduino sends too much commands, they are all put in STM32 buffer and hoverboard does not stop until it executes them all.

Please try:

• repeat process shown on video with Wheelcheck, and when wheel is disabled but does not stop, disconnect TX wire. If i am right, it will still not stop.
• set baud rate for UART as high as possible (250000, 500000, 1000000, 2000000 - which one still will work)
• after you send a command to hoverboard with Serial1.write(), let's wait for a couple of milliseconds: add delayMicroseconds(2000) and see if it helps. It is dirty, but just for finding where problem is.

Also, I prefer FEdit for testing FFB effects. In a game you don't really know what game is trying to tell. FEdit allows to create any effect with any parameters, isolated. Try to create a single Constant force effect with 1-2 seconds duration and see will it perform it and stop or not.

fvaout command in AFFBWheel can also be useful, it outputs FFB value to Rz axis in realtime, and you can use an app like VKB Joytester to display graph of wheel position and FFB force. Thus, you can see if there is a lag between FFB command and real wheel movement.