Retired Rideshare Scooter Skips the Reverse Engineering to Ride Again

[Adam Zeloof] (legally) obtained a retired electric scooter and documented how it worked and how he got it working again. The scooter had a past life as a pay-to-ride electric vehicle and “$1 TO START” is still visible on the grip tape. It could be paid for and unlocked with a smartphone app, but [Adam] wasn’t interested in doing that just to ride his new scooter.

His report includes lots of teardown photos, as well as a rundown of how the whole thing works. Most of the important parts are in the steering column and handlebars. These house the battery, electronic speed controller (ESC), and charging circuitry. The green box attached to the front houses a board that [Adam] determined runs Android and is responsible for network connectivity over the cellular network.

To get the scooter running again, [Adam] and his brother [Sam] considered reverse-engineering the communications between the network box and the scooter’s controller, but in the end opted to simply replace the necessary parts with ones under their direct control. One ESC, charger, and cheap battery monitor later the scooter had all it needed to ride again. With parts for a wide variety of electric scooters readily available online, there was really no need to reverse-engineer anything.

Ridesharing scooter startups are busy working out engineering and security questions like how best to turn electric scooters into a) IoT-connected devices, and b) a viable business plan. Hardware gets revised, and as [Adam] shows, retired units can be pressed into private service with just a little work.

The motors in these things are housed within the wheels, and have frankly outstanding price-to-torque ratios. We’ve seen them mated to open-source controllers and explored for use in robotics.

Fail of the Week: Power Wheels Racing Series

[ITMAN496] and his local HAM radio group entered the Power Wheels Racing Series with great intentions, a feeling of unlimited power, and the universal spirit of procrastination all hackers share.

It wasn’t the first time his group had worked together on something a little different, such as a robot that can deploy an antenna by climbing poles. However, this one had a time limit and they ended up trying to fit it all in the week before the race.

They had a pretty good design. [ITMAN496] had modeled the entire frame in SketchUp and even did physics simulations to get the steering just right. However, the best laid plans of mice and men often don’t fully take into account just how hard it is to get the motor drivers they bought working.

In the end, what they really needed was time to test. The setscrews couldn’t hold the motor on the shaft, the electronics needed debugging, and one of the belts was too long. The design was solid, but without time to percussively maintain the last bugs out of the system, it just wasn’t going to run.

[ITMAN496] is taking this lesson properly; he’s already planning for next year’s run, but this time he’ll have time to test. We must commend him — the build under these time constraints was still impressive. Even more so that he took the time to document everything while it was happening, and to share the story of shortfall after the fact. We’re always on the hunt for documented fails (the best way to really learn something).