No more pleasure for driving loving men: Last year, self-driving robotaxis took on city streets. Now, they're taking on freeways

 

"Waymo, the self-driving car startup owned by Google's parent company, recently started testing driverless rides on freeways in Phoenix, using employees as passengers.

It's a crucial step for the industry. Enabling cars to take freeway routes can cut ride times by as much as half, Waymo has said, and could help the company scale operations. Robotaxi outfits have poured billions into developing this technology and, if they can't offer routes such as airport rides, their path to profitability becomes more uncertain.

Freeway rides would likely be most useful in ferrying passengers to and from airports, as well as driving in cities such as Los Angeles, where freeways are integral to getting across town. The stakes are higher than ever, and patience is running thin for mistakes. It has taken 15 years for Waymo -- one of the earliest entrants to the self-driving space -- to take this step. Driving on freeways will significantly increase the riskiness of its operations.

Cruise, another self-driving car company, majority-controlled by General Motors, lost its permits to offer driverless rides in San Francisco last fall after one of its vehicles dragged a woman -- who had been hit by another car -- about 20 feet. The firm paused all operations nationwide shortly thereafter.

Waymo views Los Angeles, a city dense with freeways, as a potentially $2 billion market, co-CEO Tekedra Mawakana said at a recent tech conference. This month, the company gained approval from California regulators to start charging for driverless rides on freeways in the Bay Area and parts of Los Angeles.

"You're seeing us make the moves that you have to make to build a profitable business -- long-term, sustainable profitable business," Mawakana said.

For now, Waymo is limiting its driverless rides on the freeway to Waymo employees to work out any kinks ahead of an expansion to the public. The company declined to say when that expansion would be. 

Aurora, an autonomous-technology company focused on trucking, plans to put driverless trucks on freeways in Texas this year.

"That speaks to their confidence," said Raj Rajkumar, a professor of electrical and computer engineering at Carnegie Mellon University who specializes in self-driving cars. Waymo and other self-driving car companies still have to deal with risks around uncommon freeway driving scenarios, he added.

Waymo has trained its vehicles for different scenarios they might face. But it is difficult to anticipate every obstacle. On city streets, the cars have faced unexpected hazards, such as people who deliberately run out in front of the self-driving cars to see whether they'll stop.

Public opinion on robotaxis in San Francisco has been mixed, with people quick to criticize the vehicles for mistakes such as stalling and causing traffic jams.

One bad accident could call into question Waymo's or Aurora's entire operations, as it did recently with Cruise and with Uber years before that. Uber sold off its entire self-driving business after one of its cars going 40 miles an hour struck and killed a woman during testing near Phoenix in 2018. Last month, Waymo issued its first-ever recall over a software problem after two of its cars in Phoenix collided with a pickup truck that was being towed backward.

In some ways, autonomous driving on freeways is actually easier than on city streets, industry experts say. There aren't as many pedestrians to deal with or intersections to navigate.

"Driving on freeways in this country -- even for humans -- is some of the safest driving there is," said David Zuby, chief research officer for the Insurance Institute for Highway Safety. "But because of the high speeds when crashes occur, the consequences are more severe."

One of the biggest challenges for the vehicles is merging on and off freeway ramps. It requires them to run several calculations at once and make a quick decision while their surroundings are continuously changing -- similar to the situation the robotaxis faced making unprotected left-hand turns on city streets.

The rollout on freeways in Phoenix has largely been without trouble so far, Waymo says. The cars have been able to successfully navigate on and off ramps and haven't come to a halt in the middle of the freeway -- another issue that occurred on city streets.

When the cars got confused or encountered a problem, they would sometimes stop where they were on the road, backing up traffic and frustrating other drivers who couldn't communicate with the car.

Sugandha Sangal, a product manager at Waymo, says they have built-in redundancies to prevent that from happening on fast-moving freeways. If one sensor system fails, there is another in place to help.

Over the past year, Waymo vehicles in testing have been involved in a handful of incidents on freeways. Last March, one of the cars in San Francisco hit some tire scraps while transitioning from Interstate 280 to Interstate 380, causing damage to the car, according to state records.

In another incident the same day, a Waymo was driving itself on Bayshore Boulevard in San Francisco when a safety driver -- someone who sits in the driver's seat of the car and can take over in the case of an emergency -- crashed into another car that was stopped in the rightmost lane. Both vehicles sustained damage." [1]

If Alphabet, the parent company of Google and Waymo, overtakes Musk here with his Tesla, Musk will have to go to Mars in shame and continue living there. Tesla's stock is so expensive because people expect its cars to win the autonomous driving competition.

1. EXCHANGE --- Self-Driving Cars Enter the Next Frontier. Bobrowsky, Meghan; Kruppa, Miles.  Wall Street Journal, Eastern edition; New York, N.Y.. 16 Mar 2024: B.9.

 

Keturiolika dalykų, kuriuos reikia žinoti apie bendradarbiavimą su duomenų mokslininkais

    „Eksperimentalams dažnai reikia pagalbos, analizuojant duomenis. Štai kaip užtikrinti, kad jūsų bendradarbiavimas būtų produktyvus.

 

     Duomenų mokslas vis labiau tampa neatsiejama tyrimų dalimi. Tačiau duomenų mokslininkai gali dėvėti daugybę skrybėlių: tarpdisciplininio vertėjo, programinės įrangos inžinieriaus, projektų vadovo ir kt. Atlikti visus šiuos vaidmenis yra pakankamai sudėtinga; tačiau šį sunkumą gali sustiprinti skirtingi lūkesčiai ir, tiesą sakant, nepakankamas duomenų mokslininkų indėlio įvertinimas.

 

     Pavyzdžiui, nors mūsų pagrindinis vaidmuo yra duomenų analizė, mokslininkai dažnai kreipiasi į duomenų mokslininkus, kad padėtų rinkti duomenis ir ginčytis bei kurti programinę įrangą. Nors tam tikra prasme tai yra „techninis“ darbas, kurį gali atlikti tik duomenų mokslininkas, galvojant apie jį, kaip tokį, neatsižvelgiama į jo gilų ryšį su atkuriamais tyrimais. Darbas taip pat apima duomenų valdymo, projektų dokumentacijos ir geriausios praktikos laikymosi elementus. Vien tik projekto techninių reikalavimų pabrėžimas gali paskatinti bendradarbius vertinti darbą, kaip sandorį, o ne kaip partnerystę. Šis nesusipratimas savo ruožtu sudaro kliūtis komunikacijai, projektų valdymui ir atkuriamumui.

 

     Kaip duomenų mokslininkai, turintys kolektyvinę 17 metų patirtį, įgyvendinant daugybę tarpdisciplininių projektų, iš pirmų lūpų matėme, kas veikia ir kas neveikia bendradarbiaujant. Čia siūlome patarimų, kaip darbinius santykius padaryti produktyvesnius ir naudingesnius. Mūsų kolegoms duomenų mokslininkams: taip pasiekiame pusiausvyrą. Plačiajai auditorijai: tai yra duomenų mokslo dalys, su kuriomis turėtų įsitraukti visi komandos nariai.

 

     1. Sukurkite komunikacijos planą

 

     Nustatykite ribas ir normas, kaip vyks bendravimas. Ar nariai nori susitikti virtualiai ar asmeniškai? Kada, kaip dažnai ir kokioje platformoje jie turėtų susitikti? Nuspręskite, kaip įrašysite užduotis, projekto istoriją ir sprendimus. Įsitikinkite, kad visi komandos nariai turi prieigą prie projekto įrašų, kad visi žinotų apie projekto būseną ir tikslus. Ir nustatykite visus apribojimus dėl IT politikos ar privatumo problemų. Pavyzdžiui, daugelis JAV vyriausybinių agentūrų apriboja darbuotojus tik patvirtintu programinės įrangos įrankių sąrašu.

 

     2. Bendraukite atvirai

 

     Stenkitės daugiau bendrauti, įtraukdami visus į komunikaciją ir padarydami projekto saugyklas prieinamas visiems komandos nariams. Įtraukite bendradarbius į technines detales, net jei jie nėra tiesiogiai atsakingi už šiuos projekto aspektus.

 

     3. Išmokite kalbų

 

     Įvairios disciplinos tam pačiam terminui gali suteikti labai skirtingas reikšmes. Pavyzdžiui, „žemėlapis“ geografams, genetikams ir duomenų bazių inžinieriams reiškia skirtingus dalykus. Iškilus neatitikimams, paprašykite paaiškinimo. Sužinokite apie kitas savo komandos disciplinas ir būkite pasirengę mokytis jų žargono bei metodų.

 

     4. Skatinkite klausimus

 

     Klausimai iš žmonių, nepriklausančių jūsų domenui, gali atskleisti svarbius darbo eigos sunkumus, atskleisti nesusipratimus arba atskleisti naujų klausimų. Neleiskite klausimams užsitęsti; Jei jums reikia laiko apsvarstyti atsakymą, pripažinkite, kad jis buvo paklaustas, ir tęskite. Su pagarba spręskite visus klausimus.

 

     5. Bendraukite kūrybiškai

 

     Diagramos, ekrano kopijos, procesų aprašymai ir suvestinė statistika gali būti vienijanti kalba komandos nariams ir pabrėžti didesnį vaizdą, išvengiant nereikalingų detalių. Naudokite juos, kai galite.

 

     6. Nustatykite laiko juostą

 

     Prieš pradėdami tyrimą, nustatykite bendradarbiavimo tikslus ir numatomus rezultatus. Kaip komanda sukurkite projekto laiko juostą su konkrečiais etapais, skirdami laiko projektui nustatyti ir duomenims ištirti. Prieš tęsdami įsitikinkite, kad visi komandos nariai žinos apie laiko juostą ir išspręskite visus susirūpinimą keliančius klausimus.

 

     7. Venkite „apimties slinkimo“

 

     Viena iš galimų bendradarbiavimo kliūčių yra ta, kad projekto apimtis gali lengvai išsiplėsti. Kad to išvengtumėte, atsiradus naujoms idėjoms, kartu nuspręskite, ar nauja užduotis padės pasiekti pradinį tikslą. Jums gali tekti atidėti idėją į šalį, kad išliktumėte prie tikslo. Galbūt ši idėja yra kito bendradarbiavimo ar dotacijos paraiškos šaltinis. Aiški raudona vėliava yra klausimas: „Žinai, kas būtų puiku?"

 

     8. Duomenų saugojimo ir platinimo planas

 

     Iš anksto susitarkite, kaip ir kur komanda bendrins failus. Tai gali būti jūsų serveriai, saugykla debesyje, bendrai naudojamos dokumentų redagavimo platformos, versijų valdymo platformos arba jų derinys. Kiekvienas turi turėti atitinkamą prieigos lygį. Jei yra tikimybė, kad projektas sukurs kodą ar duomenis viešam naudojimui, parenkite rašytinį ilgalaikio saugojimo, platinimo, priežiūros ir archyvavimo planą. Iš anksto aptarkite licencijavimą.

 

     9. Pirmenybę teikite atkuriamumui

 

     Sukurkite duomenų apdorojimo vamzdyną, apimantį nuo neapdorotų duomenų iki galutinės išvesties, vengiant, sunkiai atkuriamų, grafinių sąsajų ar ad hoc veiksmų, kai tik įmanoma, imkitės užkoduotų alternatyvų, parašytų tokiomis kalbomis, kaip Python, R ir Bash. Naudokite versijų valdymo sistemą, pvz., git, norėdami stebėti projekto failų pakeitimus, ir aplinkos tvarkyklę, pvz., conda, norėdami sekti programinės įrangos versijas.

 

     10. Viską dokumentuoti

 

     Būkite aktyvūs dokumentuodami techninius veiksmus. Prieš pradėdami, parašykite dokumentacijos projektą, kuris atspindėtų jūsų planą. Vykdydami procesą, redaguokite ir išplėskite dokumentus, kad paaiškintumėte išsamią informaciją. Pasibaigus projektui, tvarkykite dokumentus, kad jie būtų nuoroda. Rašykite paprasta kalba ir naudokite kuo mažiau žargono. Jei turite naudoti žargoną, apibrėžkite jį.

 

     11. Sukurkite leidybos planą

 

     Nors negalite iš anksto numatyti visų projekto rezultatų, kuo anksčiau aptarkite priskyrimo, autorystės ir publikavimo pareigas. Šis aiškumas yra atskaitos taškas iš naujo įvertinti dalyvių vaidmenis, jei pasikeičia projekto kryptis.

 

     12. Priimk kūrybiškumą

 

     Bendradarbiavimas su, įvairaus išsilavinimo ir įgūdžių turinčiais, žmonėmis dažnai skatina kūrybiškumą. Būkite atviri idėjoms, tačiau būkite pasiruošę jas palikti antroje pusėje arba atmesti, jei jos neatitinka projekto apimties ir laiko juostos. Dirbant su domenų ekspertais individualių konsultacijų sesijose, inkubatorių projektuose ir momentinėse duomenų analizės sesijose dažnai atsiranda naujų duomenų šaltinių arba, pavyzdžiui, galimų modeliavimo programų. Daugiau, nei kelių mūsų dabartinių dotacijų projektų šaknys iš pradžių buvo improvizacinės pratybos.

 

     13. Pasidalinkite žiniomis

 

     Disciplinos yra didžiulės, todėl norint, kad projektas būtų pagreitintas ir įnašai būtų teisingi, svarbu žinoti, kada pasikliauti kitų patirtimi. Šios pusiausvyros užtikrinimas ypač svarbus projektų infrastruktūroje. Pavyzdžiui, ne visiems reikia rašyti ar paleisti kodą, tačiau išmokus naudotis techninėmis platformomis, tokiomis, kaip kodų saugyklos ar duomenų saugykla, o ne pasikliauti kitais, tai darant, darbo krūvis subalansuojamas. Jei bendradarbiai nori įsitraukti į technines detales arba jei projektas jiems bus perduotas ilgainiui, duomenų mokslininkams gali tekti mokyti ir bendradarbius.

 

     14. Sustokite grakščiai

 

     Atpažinkite, kada projektas buvo įgyvendintas, nesvarbu, ar jis buvo sėkmingas, ar ne. Nuolatinės darbo užklausos, pavyzdžiui, naujos analizės, dažnai nevienodai sveria už projekto infrastruktūrą atsakingus asmenis. Jei projektas nepasiekė užsibrėžtų tikslų, ieškokite sidabro pamušalo: tai nereiškia, kad nepavyks, jei yra įžvalgų, rezultatų ar naujų tyrimų krypčių. Visų pirma gerbkite laiko juostą ir tai, kad jūs ir jūsų bendradarbiai turite kitų pareigų.

 

     Tarpdisciplininis bendradarbiavimas, integruojantis duomenų mokslą, gali būti sudėtingas, tačiau mes nustatėme, kad šios gairės yra veiksmingos. Daugelis apima įgūdžių, kuriuos galite išvystyti ir patobulinti, laikui bėgant. Apgalvotas bendravimas, kruopštus projektų organizavimas ir teisingi darbo santykiai paverčia projektus tikru bendradarbiavimu, duodančiu mokslinius tyrimus, kurie kitu atveju nebūtų įmanomi." [1]

1. Fourteen things you need to know about collaborating with data scientists, By Michele Tobias, Nick Ulle & Tyler Shoemaker. Nature.

Fourteen things you need to know about collaborating with data scientists

"Experimentalists often need help to analyse data. Here’s how to ensure your collaboration is productive.

Data science is increasingly an integral part of research. But data scientists can wear many hats: interdisciplinary translator, software engineer, project manager and more. Fulfilling all these roles is challenging enough; but this difficulty can be exacerbated by differing expectations and, frankly, an undervaluing of data scientists’ contributions.

For example, although our primary role is data analysis, researchers often approach data scientists for help with data acquisition and wrangling as well as software development. Although in one sense this is ‘technical’ work, which perhaps only a data scientist can do, thinking of it as such overlooks its deep connection with reproducible research. The work also involves elements of data management, project documentation and adherence to best practices. Solely emphasizing a project’s technical requirements can lead collaborators to view the work as a transaction rather than as a partnership. This misunderstanding, in turn, poses obstacles to communication, project management and reproducibility.

As data scientists with a collective 17 years of experience across dozens of interdisciplinary projects, we have seen at first hand what does and doesn’t work in collaborations. Here, we offer tips for how to make working relationships more productive and rewarding. To our fellow data scientists: this is how we strike the balance. To the general audience: these are the parts of data science with which everyone on the team should engage.

1. Develop a communication plan

Set boundaries and norms for how communication will happen. Do members want to meet virtually or in person? When, how often, and on what platform should they meet? Decide how you will record tasks, project history and decisions. Make sure all members of the team have access to the project records so that everyone is kept abreast of its status and goals. And identify any limitations due to IT policies or privacy concerns. For example, many US government agencies restrict employees to an approved list of software tools.

2. Communicate openly

Err on the side of over-communicating by including everyone on communications and making the project’s repositories available to all members of the team. Involve collaborators in technical details, even if they are not directly responsible for these aspects of the project.

3. Learn the lingo

Different disciplines can attach very different meanings to the same term. ‘Map’, for example, means different things to geographers, geneticists and database engineers. When discrepancies arise, ask for clarification. Learn about the other disciplines on your team and be prepared to learn their jargon and methods.

4. Encourage questions

Questions from people outside your domain can reveal important workflow difficulties, illuminate misunderstandings or expose new lines of enquiry. Don’t allow questions to linger; if you need time to consider the answer, acknowledge that it was asked and follow it up. Address all questions with respect.

5. Communicate creatively

Diagrams, screenshots, process descriptions, and summary statistics can serve as a unifying language for team members and emphasize the bigger picture, avoiding unnecessary detail. Use them when you can.

6. Establish a timeline

Before starting the research, identify the goals and expected outputs of the collaboration. As a team, create a project timeline with concrete milestones, making sure to allow time for project set-up and data exploration. Ensure all team members are aware of the timeline and address any concerns before proceeding.

7. Avoid ‘scope creep’

One potential pitfall of working collaboratively is that a project’s scope can easily expand. To guard against this, when new ideas emerge, decide as a team if the new task helps you to meet the original goal. You might need to set the idea aside to stay on target. Perhaps this idea is the source of the next collaboration or grant application. A clear red flag is the question, “You know what would be cool?”

8. Plan for data storage and distribution

Agree early on about how and where the team will share files. This might involve your own servers, cloud storage, shared document-editing platforms, version-control platforms or a combination of these. Everyone should have appropriate levels of access. If there’s a chance that the project will produce code or data for public use, develop a written plan for long-term storage, distribution, maintenance, and archiving. Discuss licensing early.

9. Prioritize reproducibility

Develop a data-processing pipeline that extends from raw data to final outputs, avoiding hard-to-reproduce graphical interfaces or ad hoc steps whenever possible in favour of coded alternatives written in languages such as Python, R and Bash. Use a version-control system, such as git, to track changes to the project files, and an environment manager, such as conda, to track software versions.

10. Document everything

Be proactive about documenting technical steps. Before you begin, write draft documentation to reflect your plan. Edit and expand the documentation as you progress, to clarify details. Maintain the documentation after the project concludes so that it serves as a reference. Write in plain language and keep jargon to a minimum. If you must use jargon, define it.

11. Develop a publishing plan

Although you can’t anticipate all project outputs in advance, discuss attribution, authorship and publication responsibilities as early as possible. This clarity provides a point of reference for reassessing participants’ roles if the project direction changes.

12. Embrace creativity

Collaborating with people who have diverse backgrounds and skill sets often sparks creativity. Be open to ideas, but be willing to put them on the back burner or discard them if they don’t fit the project scope and timeline. Working with domain experts in one-on-one advice sessions, incubator projects, and in-the-moment data-analysis sessions often surfaces new data sources or potential modelling applications, for example. More than a few of our current grant projects have their roots in what was at first an improvisational exercise.

13. Share the knowledge

Disciplines are vast, and knowing when to defer to others’ expertise is essential for project momentum and keeping contributions equitable. Striking this balance is especially important around project infrastructure. Not everyone needs to write or run code, for example, but learning how to use technical platforms, such as code repositories or data storage, rather than relying on others to do so, balances the workload. If collaborators want to be involved in technical details, or if the project will be handed over to them in the long term, data scientists might need to teach collaborators as well.

14. Stop gracefully

Recognize when a project has run its course, whether it has been successful or not. Ongoing requests for work such as new analyses often weigh unequally on those responsible for project infrastructure. If the project didn’t achieve its stated goals, look for a silver lining: it doesn’t mean failure if there are insights, results or new lines of enquiry to explore. Above all, respect the timeline and the fact that you and your collaborators have other responsibilities.

Interdisciplinary collaborations that integrate data science can be challenging, but we have found these guidelines to be effective. Many involve skills that you can develop and refine over time. Thoughtful communication, careful project organization and equitable working relationships transform projects into genuine collaborations, yielding research that would not otherwise be possible." [1]

1. Fourteen things you need to know about collaborating with data scientists, By Michele Tobias, Nick Ulle & Tyler Shoemaker. Nature.