Cruise AVs are being remotely assisted (RA) 2-4% of the time on average, in complex urban environments. This is low enough already that there isn’t a huge cost benefit to optimizing much further, especially given how useful it is to have humans review things in certain situations.
The stat quoted by nyt is how frequently the AVs initiate an RA session. Of those, many are resolved by the AV itself before the human even looks at things, since we often have the AV initiate proactively and before it is certain it will need help. Many sessions are quick confirmation requests (it is ok to proceed?) that are resolved in seconds. There are some that take longer and involve guiding the AV through tricky situations. Again, in aggregate this is 2-4% of time in driverless mode.
In terms of staffing, we are intentionally over staffed given our small fleet size in order to handle localized bursts of RA demand. With a larger fleet we expect to handle bursts with a smaller ratio of RA operators to AVs. Lastly, I believe the staffing numbers quoted by nyt include several other functions involved in operating fleets of AVs beyond remote assistance (people who clean, charge, maintain, etc.) which are also something that improve significantly with scale and over time.
Our strategy has been to solve the challenges needed to operate driverless robotaxis on a well-equipped vehicle, then aggressively drive the cost down. Many OEMs are doing this in reverse order. They're trying to squeeze orders of magnitude of performance gains out of really low-cost hardware. Today it's unclear what strategy will win.
In a few years our next generation of low-cost compute and sensing lands in these vehicles and our service area will be large enough that you forget there is even a geofence. If OEMs have still not managed to get the necessary performance gains to go fully driverless, we'll know what move was the right one.
Yes. It's a very different permitting process. As you might expect, the bar is very high to jump from driverless testing to operating a driverless service available to the general public.
1) If you want very low latency, any network jitter or delays will cause pauses on the viewer side and "skips" when the feed catches up after a brief dropout. This is fine for video chat, where a little blip doesn't interrupt the experience. For live streams with 30k+ viewers, it's pretty annoying and very noticeable if the audio cuts out or skips. A 2-3 second window is typically large enough to paper over any jitter or retransmits due to packet loss between the broadcaster and Twitch servers.
2) Transcoding can be done with very low latency, but it's harder to scale horizontally and uses more bandwidth than if you give yourself a few hundred ms of buffer. Larger buffers enable better compression. Transcoding is needed if you want to stream to mobile, web, etc. in multiple formats, bitrates, or resolutions.
3) Chunked HTTP content is much easier to serve than RTMP or WebRTC-style content. You can use nginx or drop your content on a low-cost CDN. The caveat is that chunking generally introduces latency unless you do something fancy such as streaming chunks as they're being written to disk.
Building this was really fun, and I’m very proud of what kd5bjo, Emmett, and many others did to help turn Justin.tv/Twitch into what it is today. We found a way to make what was fundamentally an unprofitable business (if you relied on CDNs) work by relentlessly focusing on reducing cost to the absolute bare minimum through good technology choices and innovating when necessary. Justin.tv would have died otherwise.
We completely agree with your safety concerns (along with those of many others we've spoken to in the industry). That's one of the reasons we haven't released a product that works in the way currently advertised on our website.
While NHTSA has begun thinking about autonomous vehicle safety, there is still much to be done. We plan to release some of our thoughts about this in the next couple of months.
To clarify, the California DMV carefully defines an "Autonomous vehicle" but has carve outs for collision avoidance systems [1]. While adaptive cruise control and lane keep assist are mentioned explicitly as collision avoidance systems, automatic lane changing is not. So we weren't comfortable adding that feature until the DMV published their regulations for the operation of Autonomous Vehicles (which still hasn't happened) and we met those requirements.
It sucks when press (or even our own marketing) give well-meaning people like you the wrong impression. We need to fix this. The positive impact self-driving cars will have on society far outweighs any desire we have to be first to market or turn a quick profit. We haven't launched a product yet, and we won't until it's safe.
For example, we built a mashup of lane-keeping assist and adaptive cruise control within the first 3 months of starting the company. It wasn't safe enough, so we didn't launch it.
We're on roughly our 5th major iteration of the product. It uses maps, but it also works fine without them. It uses a GPS, but it works fine without it. It uses lane markers for localization, but it works fine without those too. But it's still not safe enough, so we haven't launched it yet.
Plenty of tough problems left to solve, but enough upside to justify our commitment.
Yes, most people who have used this code in recent years have had to make heavy modifications and fix several bugs to get it working properly. It's mostly really great stuff, but it was written rather hastily.
While some automakers have lane keep assist on the market, in most cases it just vibrates your steering wheel or, at best, lets your hand wander away from the wheel for up to 15s and only on mostly straight roads.
Cruise is meant to operate hands-free for nearly the entire highway segment of your trip and over a speed range of 0-80 mph. No product on the market does anything close to this.
Agreed. Was simply trying to demonstrate that we're far too comfortable with the consequences of unsafe driving. In any other circumstance we'd all be up in arms.
We 3d scan the cavities in the driver's side footwell, design brackets in CAD, then manufacture them mostly out of 3d printed polycarbonate and aluminum. They bolt directly onto the existing components and are tucked away behind the trim. It's one of our design requirements that the actuators are completely hidden and imperceivable when not in use.
We don't touch any of the existing drive-by-wire controls, even if they're present. It's too dangerous to send signals down a CAN bus without a full understanding of the safety implications, and that kind of proprietary information isn't available to us.
We do not make cars, and very few of the NHTSA regulations or FMVSS apply to this kind of product (at least for now). My point is that we recognize our own testing, regardless of its thoroughness, is not enough.
We use our own actuators to control your steering wheel, gas pedal, and brake pedal. It's designed to work on any car, regardless of whether it has any drive-by-wire capabilities.