All credit to comma.ai team for uploading original high quality video on their official ru-vid.com | comma.ai/shop/products/three ($2199) | comma.ai/jobs | Buy comma.ai/shop (Merch) | Follow the official ru-vid.com for more videos. Stay up to date by following twitter.com/comma_ai | Support comma.ai at comma.ai/shop. Chapters: 00:00 Intro Robbe Derks 00:41 How can something like comma exist? 01:06 How does a modern car work? 02:50 ECU communication 03:54 ECU communication: CAN 04:30 Why CAN? 05:22 How do we control the car? 05:29 Connecting to the car 08:02 Car connection: Giraffes 09:04 Car connection: car harness 10:05 Car harness connectors 10:34 Car harness Hyundai 10:50 Comma cabana 11:50 DBC files 12:58 Sending better control messages 13:14 Openpilot services (daemons) 13:34 Camerad and modeld 13:48 Sensord 13:54 Controld 14:08 Panda and the car 14:39 Controlsd in depth 15:33 Car interfaces 16:08 Safely controlling the car 16:24 SAFETY.md 17:21 Panda safety 17:59 Panda safety limits 18:54 How can something like comma exist recap 19:03 Cars are more simillar then they look 19:29 Most of the code base is generic 19:44 Hardware differences are abstracted away 20:02 Time for questions 20:15 Issues with openpilot sending messages instead of the car 21:20 Tesla openpilot support 22:06 Tesla Autopilot vs comma.ai openpilot 22:30 How are the safety limits decided 23:23 How are the claims about safety validated 24:19 ISO 26262 certification 25:09 Clarification about ISO 26262 25:21 MISRA C, Cppcheck 25:32 Data from blindspot radars 26:16 Car harness and more cameras in the future 26:50 Hardware fail-safes and faults safety 27:45 Panda safety range limits and dropping vs keeping messages over/below the limits 28:45 Hardware OEM blocking comma hardware 29:41 George Hotz will break it if he will need to 29:52 Dropping the packets vs clamping the packets to maximum value of the limit 30:47 Modifying the firmware on the car modules 31:29 Improving openpilot documentation 31:48 Cars with different topology 32:36 Steering motor reliability and lifespan 33:20 DBC files OEM support, comments about reverse engineering 33:40 CAN FD 33:54 Additional features via OBD 34:39 Weather/road condition speed limits/checks 35:12 Tesla over the air updates interference with openpilot 35:34 Manufacturers forking openpilot 36:01 What kind of hardware microcontrollers and latency when sending receiving messages 36:52 Features with OBD, compatiblity integration with OBD apps 37:32 Evolutionary changes, car to car communication 38:07 Sending messages on EV cars vs ICE cars 39:08 Car over the air updates breaking compatiblity and encryption 39:50 Next version of hardware 40:16 Flash utility to do updates on the car modules and controllers, ECU
Did someone, say comma, bot,? Hello! , I, am comma bot, and I am , an AI, that does, exactl,y what you, just mentioned,! I am fully automated,,, and have been, learning, using, an enormous data, set for the past 10 years,. As you can probably tell, I work pretty, much flawlessly. In order, to use, me as a tool, just type, {'text to comma-ize'} ! :,-)
What part of the code is responsible for being aware of the car's specification and capabilities? For instance, a planner might choose to take different actions if it knows that it's controlling a Ford F-150 (I don't know if it's supported or not but, hypothetically) as opposed to like a Honda Civic. The dimensions and turn radius and very different between the two. However, the name "generic" controller implies that, well, this ode is generic and hence not "aware" of the car's specification. I'd be curious to know exactly what part of the infrastructure is responsible for knowing that. Is it perhaps the safety module?
This works as long as they do not secure the bus... Not sure how long this security architecture is going to be still accepted, would have changed it a long time ago.
@@geohotarchive Might be a thing to try. All auto micros do not put much security in to avoid increasing the cost. Longer term would rethink the approach and maybe partner with OEMs.
Ok. Maybe not the ideal place to pose this question, but: Robbie states with some pride that it takes only “about 45 lines of code” to customize OpenPilot for a specific car. So if that is all the effort that is required, why is it, for example, that Comma supports the 2019 Subaru Crosstrek with Eyesight 2.0 but not the functionally identical (and likely near-identical code base) 2019 Outback with Eyesight 2.0? Asking for a friend with a 2020 Subaru Outback with Eyesight 3.0 but without the skills to add support:-). PS, the Subaru Eyesight 3.0 has fantastic Longitudinal control and actually decent Lateral, but would be brilliant with a Comma 3….
Comma can't own and test all the car models. To add support for new car the car needs to be tested properly so it can be added to openpilot. It's up to the users to add support for more cars. github.com/commaai/openpilot#community-and-contributing. Join the discord and search for info there how you can add support for your car. Usually there is not much difference between similar models so it should be quite straightforward to add support for your car. github.com/commaai/openpilot/wiki/Fingerprinting#to-add-your-car-to-future-openpilot-release You can also look at some examples from people that have done it: github.com/commaai/openpilot/pull/1768 github.com/commaai/openpilot/pull/1801 github.com/commaai/openpilot/pull/21709 github.com/commaai/openpilot/pull/21354 github.com/commaai/openpilot/pull/21382
@@WeaponGrade thats true. But it is reliable and can withstand disturbances very well. Also it is pretty cheap to implement. That’s important, especially for small ECUs and sensors/actuators. Nobody wants expensive ethernet on a door sensor. ;)
