Need Some Help?
We can help you find the information that meets your research needs.
Please call us at
+886 2 27993110
+65 90752357
+60 12 7220722
or send an email to us at mi@hintoninfo.com
IHS_EWBIEEE xploreIHS_EWB_GF

Breadcrumb

Newsroomhttp://www.hintoninfo.com.tw/

2017/10/06 GM Cruise Has a Solution, But Do They Understand the Problem?

 by Derek Viita 

In a Medium post yesterday, Kyle Vogt (CEO of Cruise Automation, acquired last year by GM) discussed his company's rationale for focusing their autonomous drive-test efforts on the roads of San Francisco.  Mr. Vogt asserts that testing in other less-dense US cities (such as Phoenix or Detroit) is easier due to the relative lack of pedestrians, construction zones, and other obstacles found in San Francisco.  In his words:  "Testing in the hardest places first means we’ll get to scale faster than starting with the easier ones."

This assertion is arguably true for a company which, at this point, is simply trying to teach a car what obstacles look like, and how they can move.  But we don't know whether this plan will work at a wider scale in other cities, because we don’t know the software behind Cruise Automation's platform, or the metrics they’re using to define success.  And we likely won't know until the first stable iteration of their autonomous Bolts are released.  But as Mr. Vogt's stated goal is "fleet deployment in the most dense urban environments," it certainly makes sense to test heavily in the environment they are targeting.

But then Mr. Vogt seems to argue that the path to scale is to simply tweak a finished self-driving product for a new city, based on learnings in San Francisco.  On that, from our consumer-focused vantage point, we vehemently disagree.  Especially if Cruise Automation's goal is to transport people, not just goods.

Urban driving certainly presents the most moving targets and unpredictable obstacles for a system to identify and adjust for.  Even so, San Francisco presents a best case scenario in a lot of ways.  Speeds are slower.  Obstacles move in closer proximity.  Lane markings and pavement are of reasonably good quality.  Weather is reasonably good.  There are lots of static obstacles to lock onto.

But when Mr. Vogt insinuates that this UX can be "easily" replicated in other cities, it indicates that, once again, the consumer is being ignored.  While teaching a car to drive itself in an urban environment is no small feat, it is also the easiest part of scaling an autonomous driving ecosystem.

Where rubber truly meets road from a UX perspective is the perceived comfort of the ride.  While it is certainly important that an autonomous vehicle keep people safe by obeying local road rules/culture and avoiding obstacles, people won’t ride if it’s not comfortable.  In our numerous worldwide consumer studies on this topic we found that comfort is, and will remain, especially crucial.

Detroit, one of the testbeds Mr. Vogt cited as "valuable," provides a perfect example of his faulty logic.  While it's true that Detroit has fewer pedestrians and construction zones than San Francisco, Detroit also has a number of other UX-critical features that San Francisco lacks.  Speeds are a bit faster.  The lane markings tend to be more faded.  Weather is significantly worse.  And most importantly, the tire-crushing potholes (which are extremely difficult to detect by many radar systems) are legendary.

GM Cruise might be able to perfect an algorithm for what they think will be an acceptable self-driving UX in San Francisco, with its close quarters, starts-and-stops, and so forth.  Perhaps comfort is already being tied to metrics such as maximum pitch, roll, and yaw.  But the assertion that a UX designed on San Francisco roads can simply be "dragged-and-dropped" into a different city with different UX-critical properties is not realistic.  If the goal is to move humans comfortably from place to place, the assertion that one urban environment is "easier" than another to design for belies a lack of understanding of the problem Cruise Automation is trying to solve.

Back