This is an unbelievably impressive project and a killer write up, very satisfying. I wonder if the author looked into using Slint [1] for the UI, given the codegen bloat issues they had with buoyant (which also looks very cool). I haven't used either, but I've done a few projects with Embassy and am always looking for an excuse to try embedded GUI tools
Heya, I tried using slint first, but slint needs even more flash, and an allocator on top. Just adding slint (with an empty UI) exhausted my binary size limit.
I've got a happy run G300 pro that has a controller I've been considering digging into. It doesn't seem tuned to the motor. This is great inspiration to start digging in. It actually seems a bit clever to use the USB pins as a CAN bus
We need to free up Bosch systems. They use lots of open source libs, but they close the whole chain (like spare batteries) so that you cannot plug external batteries from other suppliers.
Pretty much anything hardware based is like this. Everything is 100% closed source and bolted down such that inspecting it is outright impossible without extensive reverse engineering.
I believe one of the prospects we have with electric locomotion is the standardization of components: electric motors, motor controllers, batteries and battery chargers. Them being interchangeable will lead to lower costs through competition and more innovation.
It's disappointing that manufacturers are moving the other way to enable vendor lock-in. But only one manufacturer has to jump the fence and the others will be left behind.
rewriting scooter firmware in rust is the kind of unnecessary excellence i come here for. how did you debug without bricking it, swd probe or pure faith
With a SWD probe on the cracked open display initially, and this was necessary while I was still writing/porting the peripheral drivers. Once the firmware was stable (and after I'd asserted that it wasn't possible to accidentally brick the scooter) I moved to testing on the real scooter where the only feedback is if things work or not.
Thank you for posting! I got a e-scooter this spring and wrote my own app for it after reverse engineering the official app + BLE logs. I am not brave enough to do anything with the firmware on it though. Maybe not yet at least
I do not know how what the legal context is in your country, but you may need to have a device that uses public roads licensed to do so. In case of any legal issues (accidents, mostly) not only you would not be covered by your insurance, but your situation may worsen for having operated it. Something to keep in mind.
I read this as the chunks are 64 bytes and thus each chunk is split over 9 frames. I haven’t looked yet but it’s probably an ISO-TP esque framing protocol.
Yep, this is the case. Nine frames are transmitted with the first frame containing a sequence number and the first five bytes, followed by seven frames containing just data, and a final frame containing the last three bytes of data, and a two byte CRC.
I'd be pretty careful with this kind of thing. My friend vibe coded something similar and it had some very unexpected real world bugs like instantly locking the engine, cranking the engine to 100 in a second and burning the motor out, etc. So something like an escooter that you might ride across a busy road may not be the best use of vibe coding.
You don't have to fully vibe code it. Most of this stuff doesn't take massive brains, it is just super tedious - especially the reverse engineering. I've never really had the patience for that (except one USB devices that I did reverse engineer when I was younger). AI really helps with the tedium.
What make you think it is vibe coded? There is no mention of genAI being used, and the methodology looks more consistent with hand-written code he actually understands.
The firmware on these things is terrible, also larger e-mopeds btw. Like a 2 second delay on the throttle after breaking (fun when cornering!). Happy this Egret GT E-Scooter didnt turn into..’Regret’
Safe rust does not mean correct logic; best not conflate the two.
You could have perfectly safe rust that disables brakes above a certain speed, inverts steering by wire, or adjusts the charging parameters, for example (depending on addressable capabilities).
My general piece of advice to anyone looking to do this is not to even bother. Just strip the hardware package and replace it with an arduino/bb or an equivalent sbc figure out what the motors are and wire it up yourself. Way faster and less tedious
This is perhaps more of a Maker perspective. I think the article author's approach (What you might classify as embedded engineer) is more suitable broadly. These are categorizations without a fine line, but are IME useful for clustering approaches and preferences.
For another example of an adjacent non-obvious clustering, see embedded vs robotics; they don't have as much overlap as you might guess!
[1] https://slint.rs/
It's disappointing that manufacturers are moving the other way to enable vendor lock-in. But only one manufacturer has to jump the fence and the others will be left behind.
I do not know how what the legal context is in your country, but you may need to have a device that uses public roads licensed to do so. In case of any legal issues (accidents, mostly) not only you would not be covered by your insurance, but your situation may worsen for having operated it. Something to keep in mind.
Classic CAN uses 8 bytes long frame, so 64 bits. Is it a typo in the post, vor is it using CAN-FD?
My guess is a typo.
You could have perfectly safe rust that disables brakes above a certain speed, inverts steering by wire, or adjusts the charging parameters, for example (depending on addressable capabilities).
I mean. Sort of? The LLM won't go into checking random USB-C connections with an oscilloscope - it doesn't have hands, for one.
How would you know if someone bypassed the restrictions if they were riding it safely?
There is reason for speed limits, they are not there to f--k with people for fun.
This is perhaps more of a Maker perspective. I think the article author's approach (What you might classify as embedded engineer) is more suitable broadly. These are categorizations without a fine line, but are IME useful for clustering approaches and preferences.
For another example of an adjacent non-obvious clustering, see embedded vs robotics; they don't have as much overlap as you might guess!