When [Vitor Melon] found out there was a custom firmware (CFW) available for his Xiaomi Mijia M365 Pro electric scooter that would increase his top end speed, naturally he installed it. Who wouldn’t want a little more performance out their hardware? But while the new firmware got the scooter running even better than stock, he does have a cautionary tale for anyone who might decide to ride their Mijia a bit harder than the fine folks at Xiaomi may have intended.
Now to be clear, [Vitor] does not blame the CFW for the fact that he cooked the control board of his Mijia. At least, not technically. There was nothing necessarily wrong with the new code or the capabilities it unlocked, but when combined with his particular riding style, it simply pushed the system over the edge. The failure seems to have been triggered by his penchant for using the strongest possible regenerative breaking settings on the scooter combined with a considerably higher than expected velocity attained during a downhill run. Turns out that big 40 flashing on the display wasn’t his speed, but an error code indicating an overheat condition. Oops.
After a long and embarrassing walk home with his scooter, complete with a passerby laughing at him, [Vitor] opened the case and quickly identified the problem. Not only had the some of the MOSFETs failed, but a trace on the PCB had been badly burned through. Judging by the discoloration elsewhere on the board, it looks like a few of its friends were about to join in the self-immolation protest as well.
After a brief consultation with his graybeard father, [Vitor] replaced the dead transistors with higher rated versions and then turned his attention to the damaged traces. A bit of wire and a generous helping of solder got the main rail back in one piece, and he touched up the areas where the PCB had blackened for good measure.
A quick test confirmed the relatively simple repairs got the scooter up and running, but how was he going to prevent it from happening again? Reinstalling the original firmware with its more conservative governor was clearly no longer an option after he’d tasted such dizzying speeds, so instead he needed to find out some way to keep the controller cooler. The answer ended up being to attach the MOSFETs to the controller’s aluminum enclosure using thermal pads. This allows them to dissipate far more heat, and should keep a similar failure from happening again. You might be wondering why the MOSFETs weren’t already mounted this way, but unfortunately only Xiaomi can explain that one.
It may have been designed for a sewing machine, but [Haris Andrianakis] found his imported DC brushed motor was more than up to the challenge of powering his mini lathe. Of course there’s always room for improvement, so he set out to reverse engineer the motor’s controller to implement a few tweaks he had in mind. Unfortunately, things took an unexpected turn when plugging his AVR programmer into the board’s ISP socket not only released the dreaded Magic Smoke, but actually tripped the breaker and plunged his bench into darkness.
Upon closer inspection, it turned out the board has no isolation between the high voltage side and its digital logic. When [Haris] connected his computer to it via the programmer, the 330 VDC coming from the controller’s rectifier shorted through the USB bus and tripped the Earth-leakage circuit breaker (ELCB). The good news is that his computer survived the ordeal, and even the board itself seemed intact. But the shock must have been too much for the microcontroller he was attempting to interface with, as the controller no longer functioned.
Now fully committed, [Haris] started mapping out the rest of the controller section by section. In the write-up on his blog, he visually masks off the various areas of the PCB so readers have an easier time following along and understanding how the schematics relate to the physical board. It’s a nice touch, and a trick worth keeping in mind during your own reverse engineering adventures.
In the end, [Haris] seems to have a good handle on what the majority of the components are up to on the board. Which is good, since getting it working again now means replacing the MCU and writing new firmware from scratch. Or perhaps he’ll just take the lessons learned from this controller and spin up his own custom hardware. In either event, we’ll be keeping an eye out for his next post on the subject.
There’s no project that dives into existential quandaries more than a useless machine, as they can truly illustrate the futility of existence by turning themselves off once they have been powered on. Typically this is done with a simple switch, but for something that can truly put the lights out, and then re-illuminate them, [James]’s latest project is a useless machine that performs this exercise with a candle.
The project consists of two arms mounted on a set of gears. One arm has a lighter on it, and the other has a snuffer mounted to a servo motor. As the gears rotate, the lighter gets closer to the candle wick and lights it, then the entire assembly rotates back so the snuffer can extinguish the flame. Everything is built around an Arduino Nano, a motor driver powering a Pitman gear motor, and a set of Hall effect sensors which provide position data back to the microcontroller.
If you’re in the mood for a little existential angst in your own home, [James] has made the project files available on his GitHub page. We always appreciate a useless machine around here, especially a unique design like this one, and one which could easily make one recognize the futility of lighting a candle at all.
Assistive devices for people with disabilities can make an inestimable difference to their lives, but with a combination of technology, complexity, and often one-off builds for individual needs, they can be eye-wateringly expensive. When the recipient is a young person who may grow out of more than one device as they mature, this cost can be prohibitive. Some way to cut down on the expense is called for, and [Phil Malone] has identified the readily available hoverboard as a possible source of motive power for devices that need it.
Aside from being a children’s toy, hoverboards have been well and truly hacked; we’ve featured them in Hacky Racers, and as hacker camp transport. But this is an application which demands controllability and finesse not needed when careering round a dusty field. He’s taken that work and built upon it to produce a firmware that he calls HUGS, designed to make the hoverboard motors precisely controllable. It’s a departure from the norm in hoverboard hacking, but perhaps it can open up new vistas in the use of these versatile components.
There is much our community can do when it comes to improving access to assistive technologies, and we hope that this project can be one of the success stories. We would however caution every reader to avoid falling into the engineer savior trap.
Many of us will have experimented with brushless motors, and some of us will have built our own controllers rather than using an off-the-shelf part. Doing so is a good way to understand their operation, and thus to design better brushless motor powered projects. Few of us will have gone as far as [etischer] though, and embarked upon building our own controller for a 300V 90kW traction motor.
The tricky part of a high power brushless motor controller lies not in the drive but in the high-power switching arrangements. He’s using a bank of IGBTs, and to drive them he’s using a smaller industrial variable frequency drive controller with its own output transistors removed. He takes us through some of the development of the system, including showing him blowing up a set of IGBTs through having too much inductance between transistors and reservoir capacitor, and then to his final design.
This is part of a project VW first converted ten years ago, and as part of a series of videos he’s produced one going through the whole project. It’s a fascinating breakdown of the parts required for an EV conversion, and the teething troubles he’s encountered along the way.
If you want to build a small robot with a motor, you are likely to reach for an L298N to interface your microcontroller to the motor, probably in an H-bridge configuration. [Dronebot] has used L298N chips like this many times. In the video below, he uses a TB6612FNG instead, taking advantage of the device’s use of MOSFETs. The TB6612 may be a little more expensive, but it’s clearly worth it.
You can get breakout boards for the tiny chips. [DroneBot] looks at several ready-to-go breakout boards. They are not drop-in compatible, though. For example, the L298N can operate motors from 4.5 to 46V while the TB6612 can go from 2.5 to 13.5V on the motor voltage. The L298N also handles more current. However, because of its relatively low efficiency, it needs a heat sink. The TB6612 boasts up to 95% efficiency and also has a low current standby mode. Of course, the TB6612 drops much less voltage which is great if you are using low voltage motor.
Most of the projects we feature on Hackaday are built for personal use; designed to meet the needs of the person creating them. If it works for somebody else, then all the better. But occasionally we may find ourselves designing hardware for a paying customer, and as this video from [Proto G] shows, that sometimes means taking the long way around.
The initial task he was given seemed simple enough: build a display that could spin four license plates around, and make it so the speed could be adjusted. So [Proto G] knocked a frame out of some sheet metal, and used an ESP32 to drive two RC-style electronic speed controllers (ESCs) connected to a couple of “pancake” brushless gimbal motors. Since there was no need to accurately position the license plates, it was just a matter of writing some code that would spin the motors in an aesthetically pleasing way.
Unfortunately, the customer then altered the deal. Now they wanted a stand that could stop on each license plate and linger for a bit before moving to the next one. Unfortunately, that meant the ESCs weren’t up to the task. They got dumped in favor of an ODrive motor controller, and encoders were added to the shafts so the ESP32 could keep track of the display’s position. [Proto G] says he still had to work out some kinks, such as how to keep the two motors synchronized and reduce backlash when the spinner stopped on a particular plate, but in the end we think the results look fantastic. Now if only we had some license plates we needed rotisseried…
If [Proto G] knew he needed precise positioning control from the start, he would have approached the project differently and saved himself a lot of time. But such is life when you’re working on contract.