A Push Scooter is definitely a high volume consumer item requiring a dedicated motor controller and battery system. Before redesigning the controller and supporting electronics to fit it nicely into the scooter's base, an off the shelf Roboteq MBL1660 single channel motor controller was used to test and validate some innovative ideas.
Unlike all other electrical push scooters, this one does not have a hand-operated throttle. In fact, it has no visible controls at all. It is operated like any non-electric push scooters: Foot kicks to gain speed and pressing foot brake to slow down and stop. The difference is that once moving, the electric motor works to maintain that speed indefinitely. Pressing the brake cause regenerative braking to recharge the battery. Jumping off the scooter, stops the motor.
The figure below shows the system architecture
A hub brushless motor is connected to the controller via its power cables and hall sensors. The motor is from a chinese manufacturer and specially made for scooter application. Built into the hub is a planetary gear for greater torque. The hall sensor are used for commutation as well as for measuring the speed. An angle sensor is attached to the brake to sense how far the rider presses on it. The sensor is a MA3 miniature absolute magnetic shaft encoder made by US Digital with PWM output. Because it is digital output, angle can be captured by the controller with a 0.2 degrees resolution. Finally a switch detect the presence or absence of the rider.
The flow chart below show the program's operation
On all of the world's other commercial motor controllers, implementing this functionality would require asking the manufacturer to alter the product's firmware. Firmware changes are combersome and time consuming. No vendor will ever agree to this except to its best customers and for a high cost.
On the other hand, all Roboteq controllers have scripting capabilities and let the user write programs that are permanently saved into, and run from the controller’s Flash Memory. This capability is the equivalent of combining the motor controller functionality and this of a PLC or Single Board Computer directly into the controller.
Script can be simple or elaborate, and can be used for various purposes:
Complex sequencesMicroBasic Scripts can be written to chain motion sequences based on the status of analog/digital inputs, motor position, or other measured parameters. For example, motors can be made to move to different count values based on the status of pushbuttons and the reaching of switches on the path.
Adapt parameters at runtimeMicroBasic Scripts can read and write most of the controller’s configuration settings at runtime. For example, the Amps limit can be made to change during operation based on the measured heatsink temperature.
Create new functionsScripting can be used for adding functions or operating modes that may be needed for a given application. For example, a script can compute the motor power by multiplying the measured Amps by the measured battery Voltage, and regularly send the result via the serial port for Telemetry purposes.
Autonomous operationMicroBasic Scripts can be written to perform fully autonomous operations. For example the complete functionality of a line following robot can easily be written and fitted into the controller.
Compared to firmware development, scripting is very simple and quick. Code is edited in the Scripting Tab of the free Roborun PC utility. Then, clicking on the "Download" button instantly compiles the code and transfers it to the controller. The program can then imediately be executed. Scripts remain in the controller's memory permanently. Once the script is debuged, a configuration flag can be set so that the script executes every time the controller powers up. Thanks to MicroBasic scripting, the desired operation was achieved in just a couple of hours of work. See our MicroBasic scripting page for a full description of the language and a demo video. Below is a screenshot of the scrpting window.
Full program listing can be found at the end of this blog
For this project, the controller is set in closed loop speed mode. The presence switch connected to digital input 2. The angle sensor is connected to the Pulse input 1 configured in Duty Cycle capture mode.
Rider experience is as good as expected. The scooter rides exactly as a non electric one. Once kicked to some speed, the scooter keeps going without slowing down. Pressing the brake slows down the scooter while putting back energy into the battery. Pressing harder slows the scooter faster. Pressing all the way makes the metal touch the rubber of the wheel and causes hard mechanical braking.
Thanks to an off-the-shelf MBL1660 Motor controller and MicroBasic scripting, the throttling and braking method was successfuly validated in a record time. It was possible to demonstrate the scooter to potential users and resellers ahead of the final product availability.
option explicit dim Button as integer dim Speed as integer dim Brake as integer dim CurrentSpeed as integer top: Button = getvalue(_DIN, 2) Speed = (getvalue(_BSR, 1)-0) * 10 Brake = getvalue(_PI, 1) Brake = Brake -1100 ' Substract rest position if Brake < 0 then Brake = 0 ' Do not allow value to become negative if Button = 1 ' Rider is on setconfig(_OVL, 255) ' 25.5V overvoltage limit to eable motor if Brake = 0 ' Brake is off, desired speed = measured speed if Speed > CurrentSpeed then CurrentSpeed = Speed else ' Reduce speed by the amount of braking CurrentSpeed = CurrentSpeed - Brake end if else ' Rider is off CurrentSpeed = 0 setconfig(_OVL, 5) ' Force ovrevoltage detection to float motors end if if CurrentSpeed < 0 then CurrentSpeed = 0 ' Never negative speed setcommand(_G, 1, CurrentSpeed/10) ' Uncomment below to print for debug 'print(Brake,"\t",Speed,"\t",CurrentSpeed,"\r") wait(10) ' Repeat loop at 100Hz goto top