kvogt

They worked extremely hard on one problem for 10 years straight. Incredibly impressed. That's what it takes to create great things. Congrats Blake!

Cruise CEO here. Some relevant context follows.

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.

Cruise CEO here.

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.

We shared several details on how our system works and our future plans here: https://www.youtube.com/playlist?list=PLkK2JX1iHuzz7W8z3roCZ...

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.

More info at the DMV's website (although it's a lot to digest): https://www.dmv.ca.gov/portal/vehicle-industry-services/auto...

We have been running one for employees on and off since 2017.

Cruise founder here. This is kind of confusing. Short version:

- Cruise permit is for robo-taxi service, available to public (fully driverless, nobody in the car)

- Waymo permit is for robo-taxi service, available to public (human safety driver behind the wheel at all times)

- Nuro permit is for robo-delivery, available to public (no human passengers)

Tradeoffs, transcoding, and delivery.

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.

Source: I designed the video streaming network that Twitch was running when Amazon acquired it. More info here http://highscalability.com/blog/2010/3/16/justintvs-live-vid...

True. Kd5bjo is an incredible engineer.

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.

This is false.

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.

[1] https://www.dmv.ca.gov/portal/dmv/detail/vr/autonomous/bkgd

Kyle here, Cruise CEO.

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.

Mercedes-Benz has a very nice product, but it's not hands-free. There's a huge difference.

There is a fatal virus in the US that claims 3,000 people every month. And it's a nasty one. It's the #1 cause of death for teenagers. That virus is called a car accident, and the fact we're complacent with that is what scares me.

We understand the delicate balance you describe and it's our top priority to make sure our product actually does improve drivers' safety. That's why we're using independent third party testing by the same companies who test products for the major automakers, even though there is no law or regulation requiring us to do so.

At Cruise (San Francisco), we're taking the pain out of your commute. How? By making your car drive itself.

We're hiring machine learning experts, machine vision experts, and smart hackers. Also looking for a mechanical engineer and industrial designer.

Email kyle@getcruise.com

Very clever. It's Amazon-style checkout for any retail site.

Way to go Michael, Ammon, and Guillaume!

San Francisco, CA. Remote ok, but you're always welcome in the office. Full time.

Justin.tv has iOS applications with over 15 million downloads, and we're looking for a talented engineer to be the lead developer on these apps. Yes, you can work remotely and on your own schedule. Justin.tv is a fast-moving company with an incredible video technology stack. Part of the challenge in this position will be keeping up with the new features that come out and figuring out how to best format those for the mobile experience.

You will be judged based on the apps you've built and the code you've written, not your job title or education.

5 years ago it was four dudes in a two bedroom apartment trying to run a reality tv show. Web frameworks were the least of our problems, especially since none of us knew any Ruby or Python to begin with.

Hey guys. This was my call, so I guess I should explain. I'm typing from my iPhone, but here goes:

Our site is over 5 years old, and if you've followed Justin.tv at all, you know it's been pivot city. All of those pivots have left their mark on the aging code base. It also turns out that many of our assumptions about how to build and scale a high traffic web app are no longer relevant. Servers are 10x faster, bandwidth is dirt cheap, and SSD's have entirely changed the database world.

There is nothing wrong with Rails, but everything else at Justin.tv is written in Python, so I wanted to use that. Switching languages has the benefit of forcing us to remove stuff we don't need anymore and implement the minimum set of features needed; cut and paste doesn't work across programming languages the last time I checked, and that's a good thing in this case.

Django has come a long way as a framework, to the point where it no longer "gets in the way". But the main reason I like it is that it's simple and it's python. All of our backed systems and video libraries are in python, so it will be nice to be able to share more code and leverage the brainpower of the non-ruby programmers at Justin.tv. There are many.

One thing I'd like to make clear- this isn't one of those massive, paralyzing rewrite projects. Justin.tv's website alone is not terribly complex. The scope of this is limited to porting only the templates still in use, porting over the minimum set of features, and removing as much cruft as possible. Our API, chat, video, data stores, and 99% of the infrastructure are untouched.

If you want to help build what will quickly be one of the top 5 django sites in the world, I'm hiring. Team is just two developers right now (everyone else works on TwitchTV) and we're looking for a lead developer.

We spent quite a while playing with live video broadcasting from mobile phones at Justin.tv. The fundamental problem is that your Facebook friends are very rarely sitting on their newfeed during the 2-3 minutes you happen to be broadcasting, so they miss your broadcast. We never fully solved this.

For example, after looking at the data from a few hundred thousand iPhone broadcasts, we noticed that over 90% of mobile phone broadcasts were viewed after the broadcast ended. Not quite the interactive experience we (or our users) hoped for. This is exactly why we built Socialcam.

Anyways, best of luck to the Color team. This is a difficult problem and I hope they manage to find an innovative way to solve it!

congrats justin and team!

Fb connect on main signup form, regular signup a click away: signups down ~15%. Well-designed main signup form w/ fb connect as an option: signups up 8%.

30k new users per day, data statistically significant. Ymmv.