71–77 of 77 posts
So I'm not up on the Lidar industry but $12k for a sensor seems really expensive, but then again from my casual observations Lidar is really expensive. Is there a physical / first principles reason this is true or is it just really new technology?
Equivalent Velodyne lidar (the ones commonly used) cost 64K each. And no, it's my understanding that it's just a matter of volume.
Earlier quoted context omitted.
I was watching a talk from Cruise that mentions this. The main problem with cameras is dynamic range. Dealing with different lighting conditions that can change quickly is hard (the sun is really good at washing out colors). Lidar doesn't care about the current lighting conditions. https://youtu.be/s-8cYj_eh8E?t=22m39s
Also heavy rain would be a problem for regular cameras. Not just seeing through the airborne droplets, but also (at a guess far more significantly) the water directly in contact with the windscreen causing severe random distortions.
- FLIR thermal camera
- 3 different small cameras manually set at different settings, models chosen for their qualities handling light levels.
Those 4 live feeds were fed into a small black magic design quad layout device, that turned them into a single hd feed via hardware/real-time. That was fed into a hardware capture, that stacked the quad arrangement, applied some other filters and did hardware compression. At that point almost no latency was introduced but had a nice working base video feed. That was fed into the Linux box for processing.
The quad device created a sort of super hdr video, and the thermal layer took it to the next level. All of the cameras had drawbacks, but combined they were minimized.
Could hundreds of self driving cars cruising around a city with LIDAR affect the eyes of pedestrians?
The Ouster OS-1 in the article, as well as all other automotive lidars that I know of, are class 1 laser eye-safe, meaning that it is safe even if you put your eye right up to it for hours.
The power also decreases dramatically once you get far away from it, since the laser beams spend most of their time pointed in different directions, and the collimation is not perfect.
I get really excited about this technology, yet the not-made-here-syndrome force is strong in this one. I wonder if theres an EU equivalent?
However, none of those matches the capabilities of the Ouster OS-1 exactly.
The problem is that deep learning should not be allowed in safety critical systems, because (1) the accuracy is always less than 100% even in known test situations, and (2) we don't know how it works and under what conditions it breaks down.
I was in a car crash two years ago where a man went into a diabetic fit/seizure and sped through an intersection, ultimately hitting a building and my car and killing himself in the process. It is too bad his car did not have some of this deep learning that is not 100% accurate. We don't know how humans work and under what conditions they break down, either.
Passive self-driving systems that take over when the human gets distracted/unwell are great because human vision exceeds computers where as computers are always alert. This would capture the case you describe, I think it would also have a massive improvement for when bus/lorry drivers should collapse at the wheel (Elon Musk used this as a valid use case for Tesla auto-pilot in the Tesla Semi unveiling).
However active self-driving systems (e.g. Tesla's auto-pilot) are currently worse because they rely on computer vision and humans to be always alert.
Earlier quoted context omitted.
And after certification, what if the company wants to push a quick update to all of its cars every now and then, through a remote update? Would that be allowed? How would we even know that it happens?
> And after certification, what if the company wants to push a quick update to all of its cars every now and then, through a remote update? Late and a bit rough but here is my idea: Install redundant self driving units in at least a good number number of the first few thousand cars in each generation. When planning a release, push to the redundant unit in the cars already running in "production". Use only primary uni…
Earlier quoted context omitted.
> And after certification, what if the company wants to push a quick update to all of its cars every now and then, through a remote update? Late and a bit rough but here is my idea: Install redundant self driving units in at least a good number number of the first few thousand cars in each generation. When planning a release, push to the redundant unit in the cars already running in "production". Use only primary uni…
I am fascinated by the testing methodology you described (current version and proposed upgrade run in parallel in production). I hope this isn't a dumb question but is there a name for that style of testing and do their exist categories of systems for which it is commonly used?
Definitely not : )
> but is there a name for that style of testing and do their exist categories of systems for which it is commonly used
I don't know but I guess parallell deployment, production testing (hehe) or something.
I guess I learned about it here on HN but I've heard similar approaches elsewhere.
Three concrete systems I can think of that has been tested in similar but not identical ways:
- trajectory calculation systems for some space probe (I forgot the details) where two separate vendors where tasked with writing software and their software where then run in parallel in a simulation of possible trajectories to root out any bugs. Mentioned as an example to point out an extreme variant of testing, probably by someone here on HN or in something linked to from HN.
- a vendor running testing of bag sorting equipment on an airport. Probably told me from a colleague of mine at the time who knew them. AFAIK they'd rerun batches and verify the outputs, making sure the new system produced similar or better results.
- an API testing service, probably mentioned here on HN as well, tjat worked by firing three similar requests for each resource and method: two to a deployment of the old system and one to the new. The two that were fired against the old would be used to find parts of the response that changed from request to request (time stamps etc) and the the rest of the response would be used as a template to verify the response from the new system.
more generally capturing and reusing production input or running two sets of services in parallel in a data center, - or across datacenters: the existing system as usual and the system under test with only input data.