Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Comma Three Devkit

comma.ai

Post reply on HN
Print view View original

41–50 of 61 posts

Re: Comma Three Devkit

#41

Post by kelnos »

mgraczyk wrote: post #21
stefan_ wrote: post #13

Earlier quoted context omitted.

This does not in any shape or form compete in the self-driving cars space; the thing doesn't have a rear camera! This is basically the "rsync as Dropbox" approach to augmenting your car with a hacky version of automatic cruise control, with a bonus lawsuit should you ever be in a crash significant enough to warrant the attention (think paralysis).

If you haven't tried it, I would refrain from making that claim. I used the v1 of this device for ~1 year, and since then driving has never felt the same. It was sooo much less annoying to do regular commutes when the device took control for even 90% of the trip. This was true even though I still paid attention to the road and had hands ready to take the wheel.

Sure, but your experience doesn't really tell us about the overall safety of the system. How many total miles have been driven by people using a Comma system? The front page of their website says "millions", which is several orders of magnitude less than Tesla Autopilot (several billion miles at this point).

Given that in the US there is around 1 fatality per 100 million miles driven, I don't think "millions" of miles driven with Comma is anywhere near enough to say anything about its safety record.

Re: Comma Three Devkit

#43

Post by pd0wm »

nanis wrote: post #40
woodruffw wrote: post #33

I'm not anywhere near a specialist when it comes to car software, CAN, or self-driving, but I'm concerned by some of the code that (appears to) control some of the supported cars: I pulled up a random file[1], and it's littered with undocumented bytestrings that are apparently sent over the CAN bus, as magic constants (with accompanying comments that mention "aggressive" and "laggy" behavior). I have no insight into…

Ouch. The method is called `update` and it is littered with stuff like: if (frame % 10) == 0: can_sends.append(make_can_msg(1648, b'\x00\x00\x00\x40\x00\x00\x50\x00', 1)) can_sends.append(make_can_msg(1649, b'\x10\x10\xf1\x70\x04\x00\x00\x00', 1)) ... I know the identifiers etc are probably hard to catalog, but that is all the more reason to give things symbolic names and maybe even avoid having to specify those IDs…

See my other comment about Ford code being reference only.

Supported cars have most signals defined in a dbc file, the mapping from name to id and bytes. See https://github.com/commaai/opendbc

This results in much cleaner car abstraction layers: https://github.com/commaai/openpilot/blob/de0ce142ae51cf9c85...

Re: Comma Three Devkit

#44

Post by woodruffw »

kelnos wrote: post #36
woodruffw wrote: post #33

I'm not anywhere near a specialist when it comes to car software, CAN, or self-driving, but I'm concerned by some of the code that (appears to) control some of the supported cars: I pulled up a random file[1], and it's littered with undocumented bytestrings that are apparently sent over the CAN bus, as magic constants (with accompanying comments that mention "aggressive" and "laggy" behavior). I have no insight into…

On one hand I agree with you wholeheartedly (I also think python is a weird language choice for something that probably has some hard real-time requirements), but also consider that stuff like that may very well be present in the code bases of the closed-source commercial solutions, but unless someone who has worked on one of them speaks up, we'll never know.

Yeah, that's why I couched my critique a little bit: I have no insight whatsoever into the commercial side of this and, for all I know, it could be even worse!

But that alone is bloodchilling: it terrifies me, as a pedestrian and cyclist, to think that stuff like this is probably controlling the pieces of machinery that could kill me in a split second.

Re: Comma Three Devkit

#45

Post by kelnos »

treelovinhippie wrote: post #27

For those new to the comma.ai strategy: Autopilot is iOS. Openpilot is Android. Far more devices running Android than iOS in the world. And unlike consumer tech, the average car on the road is over 12 years old. So there's a long window of opportunity where we might see more people choose to upgrade their current vehicles to self-driving, versus those choosing to buy new vehicles with inbuilt self-driving hardware.

I think a big barrier to adoption here is that your Android phone most likely won't kill you if it has a bad bug[0].

Comma almost certainly won't get widespread adoption until it has enough miles driven on it (at least a billion?) for people to have enough data to start talking about its safety record. So that means it'll be stuck in the realm of enthusiasts for quite a long time.

If it does prove itself, though, I agree with you that it could be a game-changer for people who have recent enough cars to be supported, but not have their own driver-assist systems. And that's probably a lot of cars, and a lot of people.

[0] Although, with the exploding batteries debacle...

Re: Comma Three Devkit

#46

Post by kyle_martin1 »

mgraczyk wrote: post #20
kyle_martin1 wrote: post #17

Earlier quoted context omitted.

Not actually open source. The source code that’s available is a thin wrapper around a closed-source ML model. If George really cared about Open Source he would release the training architecture and training data.

As somebody who works with video and photo user data for machine learning, I'd say they are much better off not releasing the majority of their data. Unfortunately there are fairly severe legal consequences for commercial use of certain kinds of unconsented user data in various US states (consent of the people filmed, not the people collecting the data), and even companies in complete compliance have to deal with a h…

I agree with you but...you're also not claiming you're project/product is open source.

Re: Comma Three Devkit

#47

Post by woodruffw »

solarkraft wrote: post #37
woodruffw wrote: post #33

I'm not anywhere near a specialist when it comes to car software, CAN, or self-driving, but I'm concerned by some of the code that (appears to) control some of the supported cars: I pulled up a random file[1], and it's littered with undocumented bytestrings that are apparently sent over the CAN bus, as magic constants (with accompanying comments that mention "aggressive" and "laggy" behavior). I have no insight into…

There’s some messing around involved in building the interfaces to the cars. Comma’s excuse for why you shouldn’t be concerned is that both Open Pilot and the cars themselves have limits against erratic movements.

> Comma’s excuse for why you shouldn’t be concerned is that both Open Pilot and the cars themselves have limits against erratic movements.

Are these limits baked into the cars at some level beneath Comma, or do they rely on the same physical layers and networks? It makes perfect sense to me that the car has its own limits; my concern is that installing Comma takes the car outside of its expected operating parameters and that I have no real way of verifying whether those limits are still in place.

Re: Comma Three Devkit

#48

Post by kyle_martin1 »

WrtCdEvrydy wrote: post #23
kyle_martin1 wrote: post #18

Earlier quoted context omitted.

I use my comma two everyday. Works great. Support from the company is non-existent. I'm kind of pissed because I bought it in the last few months and now they've come out with another one. There should be a trade-in and upgrade program.

They're still selling comma 2 and I still think they support comma 1. I don't see what's some awesome about this new one, to be honest. I'd like the next one to add blind spot sensors for cars that don't have them.

It has better cameras. Higher dynamic range which means it can handle tunnels, shade, etc. better. The cameras can also see further which means the possibility for traffic light behavior in the future.

Re: Comma Three Devkit

#49

Post by woodruffw »

pd0wm wrote: post #43
nanis wrote: post #40

Earlier quoted context omitted.

Ouch. The method is called `update` and it is littered with stuff like: if (frame % 10) == 0: can_sends.append(make_can_msg(1648, b'\x00\x00\x00\x40\x00\x00\x50\x00', 1)) can_sends.append(make_can_msg(1649, b'\x10\x10\xf1\x70\x04\x00\x00\x00', 1)) ... I know the identifiers etc are probably hard to catalog, but that is all the more reason to give things symbolic names and maybe even avoid having to specify those IDs…

See my other comment about Ford code being reference only. Supported cars have most signals defined in a dbc file, the mapping from name to id and bytes. See https://github.com/commaai/opendbc This results in much cleaner car abstraction layers: https://github.com/commaai/openpilot/blob/de0ce142ae51cf9c85...

Thanks for the reference! That certainly does look much nicer.

That being said, I do still see some "magical" looking constants and dictionary keys here[1], as well as lots of small numbers later in the file. I think it would be confidence-inspiring to have those better documented as well.

Edit: I found some more magic-looking bytestrings in the Volkswagen support here[2].

[1]: https://github.com/commaai/openpilot/blob/de0ce142ae51cf9c85...

[2]: https://github.com/commaai/openpilot/blob/de0ce142ae51cf9c85...

Re: Comma Three Devkit

#50

Post by pd0wm »

woodruffw wrote: post #49
pd0wm wrote: post #43

Earlier quoted context omitted.

See my other comment about Ford code being reference only. Supported cars have most signals defined in a dbc file, the mapping from name to id and bytes. See https://github.com/commaai/opendbc This results in much cleaner car abstraction layers: https://github.com/commaai/openpilot/blob/de0ce142ae51cf9c85...

Thanks for the reference! That certainly does look much nicer. That being said, I do still see some "magical" looking constants and dictionary keys here[1], as well as lots of small numbers later in the file. I think it would be confidence-inspiring to have those better documented as well. Edit: I found some more magic-looking bytestrings in the Volkswagen support here[2]. [1]: https://github.com/commaai/openpilot/bl…

At some point the values have no deeper meaning and are just whatever VW decided on as their API. DBC files have concepts of enums, but that’s really diminishing returns and wouldn’t make the code that much easier to understand.

Also sometimes there are fixed values in the message that we’ve only observed as static data. Ironically that makes it impossible to reverse engineer what they mean. So those just have to be labeled as hardcoded value.

Those are actually magic. Those are the ECU firmware identifiers from the manufacturer that are used by openpilot to recognize which car it’s connected to.

Post reply on HN