Recently there have been rumblings about the next thing in micromobility: micro-autonomy. This was actually a Google April Fool’s joke in 2016. But are the pieces now actually coming together?
Using the self-driving technology stack as a framework, I’ve considered the possibility of building a self-driving bike for shared fleet use.
Tl;dr: it’s feasible to produce a self-driving bike, particularly if it uses bike lanes (or sidewalks).
First, a proposed self-driving bicycle definition:
2. Able to steer, accelerate and brake on its own
We won’t explicitly discuss remotely-controlled bikes, but some of the same benefits would apply (with less technical complexity) and I would consider them in the same category.
The self-driving bike use case is shared fleet rebalancing, i.e. when the bike has no rider and is unlikely to get a new one from its location. The potential benefits are numerous. The customer would save time, the operator would make more money and save on operational costs, and cities would better achieve their goals of inclusion and decreased environmental impact. There may also be a case for personal ownership, but we’ll focus on commercial use.
For the customer, a self-driving bike would be a magical experience. It could come to your doorstep- hail it like an Uber/Lyft today. This saves a non-trivial amount of time that one now spends walking to/from the bike or bike station.
For the operator, repositioning helps both revenue and costs. They would increase revenue via a higher utilization rate. Operators could use historical data to understand where peak demand will occur and move their bikes there automatically.
Self-driving bikes would also decrease costs due to improved maintenance and recharging operations. Today these rebalancing tasks are handled either by paid workers or incentivized customers. JUMP, Motivate, Smide and other bike share companies pay small amounts to their customers to reposition bikes. Bird, and to a certain extent Lime, effectively outsource their recharging operation- paying a bounty per scooter for transport, charging and redistribution. Other passive methods help too- charging fees for out of service area parking, for example. A self-driving bike would revolutionize this- moving itself for a near-zero cost. It could return to a maintenance facility or a neighborhood pickup spot for easy retrieval, saving the ops team valuable time. Operating costs will not be all improved, though. Maintenance of a self-driving bike with complex compute, sensors and control mechanisms will cost more than a manual e-bike.
To give a sense of the cost savings, JUMP credits a rider $5–10 to leave an e-bike with a low battery at a drop-off location. In other words, their own costs are presumably higher than this to retrieve, charge and redistribute the bike. To benchmark further using scooters, The Information calculated that Bird is spending $1.72 per ride on recharging and another $0.51 per ride on repairs.
Beyond these financial benefits, cities could benefit from self-driving bikes. An operator could ensure bikes are always properly parked and distributed to requested neighborhoods. For example, San Francisco mandates that operator JUMP provides 20% of its bikes in designated Communities of Concern. This now requires support from their operations team, relocating bikes regularly. Furthermore, bike share programs emit a small amount of greenhouse gas from their operations vehicles. This would be reduced if the bike is propelling itself with a battery instead.
Now to the question of feasibility. If bikes are in fact much easier to develop than self-driving cars, they could be launched quickly, given the state of self-driving car development. For the main autonomous vehicle (AV) systems, I’ll rate the difficulty of development compared to self-driving cars. If you are unfamiliar with AV systems, this Udacity blog post is decent.
- Much easier
- Somewhat easier
- May not be easier
A disclaimer: I am not a roboticist. This is intended as an exploration of the challenges that teams will face, not as a technical paper. It’s accurate as far as I know, but also speculative.
- Much easier. HD cameras plus ultrasonic sensors (similar to a car’s parking proximity sensors) combined with a decent computer vision system could detect and classify major hazards. This can be done with relatively lightweight compute (e.g. Comma.ai uses an Android phone).
- Somewhst easier. GPS can fix a location pretty reliably and accurately. It won’t be possible to easily get the centimeter-level precision found on self-driving cars that employ Lidars + HD maps. At low speeds when not mingling with cars, that likely is ok but notable. If these were on the road, this would be problematic since the vehicle would be unable to reliably know its lane or lane position.
Somewhat easier. The complexity of prediction hinges on the question of where these bikes would be operating- on streets, bike lanes or sidewalks. The bike lane and sidewalk are easier, but may not be an option depending on local infrastructure and laws. We’ll consider all three.
- Bike lane: cyclists that are traveling in the same direction as the self-driving bike and nearby pedestrians are most important and relatively straightforward to predict when near/in the bike lane. Situations with cars, e.g. when crossing a bike lane to turn right, are less common but also generally straightforward.
- Sidewalks: While sidewalk users tend to move in more random directions and act less predictably than cars, the low speeds mean precise prediction does not matter as much for objects that are farther away. As an aside, it’s not clear from videos released that some sidewalk robots are predicting at all. Either way, this problem is simpler to solve than for self-driving cars and that in turn means less compute needs.
- Roadway: Will face all the same complexity as self-driving cars do. In other words, very challenging.
May not be easier. Similar to prediction, it will depend on whether sidewalks, bike lanes or roadways are used.
- Bike lane: the best option for the operator and other road users. Following a clearly marked lane will be straightforward, or at least to the extent those lanes are connected… If you stayed entirely to bike lanes, you could likely avoid left turns, as those involve crossing lanes of traffic and are hard for self-driving cars today.
- Sidewalks: with relatively clear sidewalks and low speeds, planning should be straightforward and may be easier than with self-driving cars. There’s usually a single “lane” to take and you would want to center yourself in it, barring any need to route around other sidewalk users.
- Road: This would be hard. Operators would very likely need to geofence the bikes within an area with clear and uniform lanes. As any cyclist knows, selecting a path is nuanced and variable depending on road conditions, traffic volume, aggressiveness of the drivers, time of day, etc.
Much easier. See my previous post, but given multiple self-driving motorcycles (BMW, AB Dynamics) and even a bicycle (Tsinghua University) already rely on the standard brake, throttle and steering controls, this should be achievable. Self-driving motorcycles are a good analog since they have similar balance challenges, plus they share disc-brakes and propulsion via chain transferring power to the rear wheel. Given the slower speeds, it will be ok to have slightly longer reaction times for braking since the bike won’t travel far.
Hardware and software are closely linked, so I’ve considered likely specifications in brief. The critical question: whether the safety and functional requirements can be met at a low enough cost so that the unit economics work. Reach out if you’d like to see me explore this further.
- Sensors: considering function, cost, and choices by similar vehicles, cameras, GPS, IMU, ultrasonic sensors are all likely to be used. Lidar (too costly) and radar (for long distances) are unlikely.
- Power: the compute and sensors needed for this bike require significant power. For reference, the Starship self-driving sidewalk robot has a 148Wh Lithium Polymer battery weighing 2lb (~1kg) that enables two hours of (very slow) operation (specs). For reference, manual e-bikes already have up to 800Wh batteries weighing 11lb (5kg) for propulsion (ex: Stromer).
- Weight: these will be heavy- well over 100lb (45kg). Why? JUMP e-bikes weigh 70lb (32kg) without any of the sensors, compute and extra batteries needed for self-driving and balancing. Self-driving sidewalk robots, which do contain such hardware as part of a lighter chassis, weigh 50–80lb (23–36kg).
- Stabilization: While in motion, steering should keep the bike balanced. While stationary, there would be two approaches: a gyroscope and a kickstand. Gyroscopes would be power-hungry, noisy and potentially bulky. A kid’s wheel-based gyroscope (the “Jyrobike”) was launched on Kickstarter several years ago but never shipped. A kickstand would require an actuator to deploy/retract on its own.
- Safety- this deserves an entire post, but compared to self-driving cars, the safety considerations are very different. The focus needs to be on ensuring the safety of unarmored road users- cyclists, pedestrians, scooterists, since these may be sharing road space with them. Compared to a self-driving car, the self-driving bike will travel at lower speeds, has a much shorter stopping distance, a lower profile, and much lower mass. This means the severity of an incident will be lower. The best course of action in many situations will be to stop and call for help.
- Vandalism- people will have a field day if these are moving at low speeds- trying to jump aboard, push them over, etc. The vehicle will need sensors to detect this and safely stop. As discussed by Horace Dediu and Oliver Bruce, vehicle aesthetics and deployment strategy also factor into vandalism and should be considered. An ugly bike abruptly deposited into a community will not be treated as nicely.
- Customer experience- interactions must feel seamless, with the autonomy in the background.
- Regulations. For now, these would be classified as normal e-bikes, which have their own rules in some places. It can be assumed that some cities will regulate self-driving bikes, as San Francisco did to sidewalk robots in 2017. While self-driving vehicle regulations are nascent, the small size, lack of people aboard and low speeds will hopefully keep regulations from being too onerous. Expect there to be speed limits, special permitting, and limits on where the bikes can travel. These regulations will matter most in dense urban areas like Manhattan or Hong Kong. In less populated cities like Scottsdale, AZ or on a college campus, wider shoulders and walkways mean fewer potential conflicts with other people no matter where the bikes are operating.
- Top speeds. these would travel slowly, likely under 6 mph (10 kph) to ensure safety and give the vehicle ample reaction time. Another consideration is how long people will be willing to wait after hailing a self-driving bike. The magic of Uber/Lyft is that they are as reliable as running water. In urban areas, let’s assume you want to wait less than 5 minutes. That means the vehicle could move up to ~800 meters, or 4–10 blocks. The implied density feels reasonable considering current deployments.
Self-driving vehicle road testing has brought both excitement and trepidation. Hopefully, micro-autonomy like self-driving bikes will be different. It has the potential to increase access to affordable mobility by substantially improving unit economics and decreasing sidewalk clutter. An operator could provide the same service as today with many fewer vehicles given the increased utilization and efficiency. I’ve heard estimates of 5–10x fewer bikes than today’s systems. This also means fewer bikes sitting idle on the sidewalks or racks. We’re early in the journey, but much like the rapid pace of micromobility’s expansion, I expect we’ll see micro-autonomy tests within the year.
Thanks to Oliver, David, and Josh for their feedback.