> After the presumably thousands of hours of labor that went into designing this, they went with a consumer grade, off the shelf product for an application that would have required a fraction of the power it was capable of?
Driving the 3-phase motor yes, that can (and is usually) done with a dedicated real-time MCU/ASIC. But the interface with the backend, the actual brains? You need to deal with GPS, authentication (unlock via app/bluetooth/...), ride logging, debug data. And at that point an ESP32 or heaven forbid an Arduino won't cut it either, and you don't want to spend hundreds of hours on wrangling with some custom higher-power embedded board because that is real nasty to get right. So you use an RPi because the extremely broad user base has already solved every issue you might have run into.
Besides, the innards of e-scooters can be had as whitelabel solutions, no one engineers these themselves. All people do is design the outer shell based on a design kit, do whatever needs to be done to pass legal certifications, and integrate some sort of brains if it's for a fleet.
> GPS, authentication (unlock via app/bluetooth/...), ride logging, debug data. And at that point an ESP32 or heaven forbid an Arduino won't cut it either
Why? ATMega board is surely a questionable fit, but ESP32, or nRF52, or some STM32 board with Bluetooth all should be fully capable of doing the basics. I can't imagine those scooters do some fancy signal processing on-board or handle some particularly heavy traffic. ESP32 is capable of wrapping and transmitting a decent video stream (and even do some basic detection while it's at it) - surely it's much more data than some route information and various on-board telemetry. GPS and cellular are just talking over some bus to a module (pretty much the same as with rPI4), Bluetooth is available and not resource-expensive at all. So is talking to whatever relays run or block the motors - I imagine that's probably just a bunch of GPIOs. All that remains is need for some RAM to store/buffer the traces (ESP32, or one can throw in some external storage) and a basic TLS and MQTT implementation (or whatever tech would make most sense there) for the command and status message queue.
And most importantly, average ESP32 energy consumption is way smaller than rPI4's (it's pretty hot even when it idles). While I understand that scooters have large batteries, it still matters.
The ESP32 can certainly do any of those things, but where it starts to become a problem is when you want to do all of those things. You start to run into limitations on application size, IRAM, GPIO's, etc.
I've shipped ESP32-based boards and written firmware for it that really tries to cram in as many features as possible, but you do hit limits. While I almost certainly wouldn't make the choice of shipping a high-volume product with an actual Raspberry Pi in it, I do see why trying to cram all of this into an MCU is tough — especially if you're trying to get to market quickly.
Perhaps this would have been a good place to use the RPi CM4 though?
For the record, I don’t care what tech they decided to use, but I don’t see why the features you listed couldn’t be implemented with ESP32. Sounds like a fun project actually.
BLDC drivers are readily available for a variety of applications and current levels. You need only a 3.3 or 5v signals to get them to run.
The RaspberryPi is not a real time computer, it uses a conventional OS that is inherently not real time. Regardless, you don’t need anything RealTime(tm) because the throttle produces a signal to the BLDC controller, and the MCU only turns on/enables its use.
The benefits from certification are minimal of using an off the shelf product, as you are still required to have the custom stuff l certified, too. They are likely using a cellular module that carry’s its own cert which is the biggest hurdle anyway.
My point is that using a hobby-grade Linux system designed for a much different use-case shows clear deficiency in the skillset of the team, management, or hiring, this is very obviously not the right tool for the job. What makes this upsetting is the fact that the market this was made for (and still is exerting demand pressure) cannot get their hands on it because of the pressures in the industry that values something that just works over correctness. If they would have used the Rpi compute modules, it would have given them a lot of flexibility in what they chose to include while reducing costs all around. This whole thing is a masterclass in gross incompetence characterized by waste and poor engineering.
Even then a RPi Zero should have been more than enough to handle the things you listed I'd think? An RPi 4 seems like not just overkill but ridiculous overkill.
A halfway-competent operation management team would see that as a reason to make the hardware harder to repurpose, not easier. Big organized operations can figure shit out, but put some barriers in front of the script-kiddie/homeless-dude contingent.
You have to spend $$$ up front on thousands of vehicles that cost hundreds of dollars each, and your marginal revenue per ride ain't great. Putting a dent in your vehicle theft rate becomes a big deal fast.
A halfway-competent operation management team would run the numbers to see if there are enough people stealing scooters and stripping them for parts to justify developing proprietary hardware. They probably did and the answer was probably "no."
> A halfway-competent operation management team would see that as a reason to make the hardware harder to repurpose, not easier.
Given that it's a routine sport in many cities, particularly those with bodies of water, to damage or destroy the scooters, it's imperative to make them as cheap as possible and as easy to repair as possible. Both conflict with stuff like custom boards or barriers to opening them up.
Are you getting this info from financial reports or such? Cause it directly contradicts all the first- or third-party reporting I've seen from the big players in the industry. As well as the hacker discussions around trying to repurpose newer Limes and such (another link in addition to the one I put in the other subthread: https://scootertalk.org/forum/viewtopic.php?t=30090&start=10 )
The biggest theft use I see locally these days of the modern Limes and Birds is using the batteries for charging shit at homeless encampments.
But there were a million copycat companies like Spin who launched with off the shelf stuff after Bird and Lime who seemed to copy the "light money on fire theft-wise" problems of off the shelf stuff.
> The biggest theft use I see locally these days of the modern Limes and Birds is using the batteries for charging shit at homeless encampments.
Okay, I'm German, so no idea about homeless encampments because we simply don't have these in large scale, but how does that even work? Like okay, you rip out the batteries, but then what? You'd still need some sort of voltage regulator just to power a device, and that hasn't even included recharging the batteries.
None of that's very complicated electronics. Homeless != stupid. Wire some shit up once and then free mobile power is free power. Either jack another battery out of another scooter and reuse your wiring, or do some further wiring to charge off a streetlight or something if you're YOLO.
But it's a lower-demand type of theft than "spend 30 bucks on alibaba and have a free scooter forever thanks to the off-the-shelf-nature of the first rental scooters" that people in the US market were going nuts with in 2018/19. It's a bit more wild west than Germany. ;)
I suspect both of those are external module/boards plugged to the rPI. It doesn't require a degree in electronics or software engineering to unplug all connectors from the board and move the scooter away from its last location. Or, you know, just disconnect the battery.
I've no idea about those scooters, but I won't be surprised if it's all behind some plastic panel held by few screws.
This was already all over the internet 4 years ago when Lime/Bird got started and were using off the shelf vehicles.
AFAIK, somehow going after scooter thefts in cities that often already had a grumpy relationship with them for GTA never really happened. And come on, there's a LOT of people for whom "a couple hundred dollars" is a plenty big enough score. Why would anyone steal a bike in that case either?
eBikes certainly aren't classed as vehicles in the US, and no one cares when they are stolen.
Given how little prosecution there is around bike theft, I doubt any police department or prosecutor is interested in spending the resources to prosecute the theft of an even cheaper mobility device.
Driving the 3-phase motor yes, that can (and is usually) done with a dedicated real-time MCU/ASIC. But the interface with the backend, the actual brains? You need to deal with GPS, authentication (unlock via app/bluetooth/...), ride logging, debug data. And at that point an ESP32 or heaven forbid an Arduino won't cut it either, and you don't want to spend hundreds of hours on wrangling with some custom higher-power embedded board because that is real nasty to get right. So you use an RPi because the extremely broad user base has already solved every issue you might have run into.
Besides, the innards of e-scooters can be had as whitelabel solutions, no one engineers these themselves. All people do is design the outer shell based on a design kit, do whatever needs to be done to pass legal certifications, and integrate some sort of brains if it's for a fleet.