Close

Understanding the hoverboard II

A project log for OpenChair

Make your chair YOUR chair

alvaro-ferrn-cifuentesAlvaro Ferrán Cifuentes 09/17/2016 at 18:082 Comments

In the previous log we saw how to control a single wheel over UART. The natural progression is to simply plug in the second wheel and do the same thing to have complete control over the board and be able to spin the wheels at our hearts' content.

Wrong. We can spin each wheel independently as long as the other one is stopped, or move both in the same direction (making the board turn on its axis), however trying to make the board move (above a minimum speed!) along a straight line results in the wheels accelerating until they achieve the maximum allowed speed and are turned off by the beeping controller board.

While this may at first not make much sense, it actually is a very intelligent control method:

-When going at low speeds the user is able to navigate obstacles by having full control of the board and the wheels behave just as expected.

-However, going above a certain speed will trigger the "cruise mode" in which we trade fine control for a large range of speeds. In this mode the inclination controls the board's acceleration instead of its velocity, meaning that if while moving forwards the user stays in the same inclination, the board will start speeding until the users move to a vertical position, at which time the acceleration will be zero and the board will remain at the selected cruise speed. Then to decelerate it is simply a matter of turning the board slightly backwards until the it reaches either a lower cruise speed, stops completely, or starts moving in the opposite direction.

With all this in mind we have found that the way to control the board is:

-When moving at slow speeds or rotating, continue as usual.

-When moving in cruise mode first send the desired speed to the wheels and in the next iteration send a zero value, to maintain the board's velocity constant. Then to stop the board, either keep decelerating until the speed is zero, or send an emergency stop signal (simulating a fallen user) by making the sixth byte of the command a '0x000' instead of the '0x055' normally sent.

Discussions

Gert Galjoen wrote 09/24/2016 at 12:20 point

Glad I found your effort for controlling the motors. I was theoretical preparing a sort like adaption but had the MPU6050 in mind. Did you consider of fooling this input of the Cortex-M3 processor. I presume it will behave different towards the obtained/maintained rotation speed.

  Are you sure? yes | no

Alvaro Ferrán Cifuentes wrote 09/27/2016 at 11:43 point

Hi! 

Our hoverboard uses the 2 gyro board + motherboard configuration, in which the gyro boards communicate with the main one over UART. Because of this, we found it easier to simply unplug and emulate the gyro board instead of desoldering the MPU6050 and fooling the sensor fusion processors. 

  Are you sure? yes | no