Something along this lines is the real danger. People will understand common failure modes and assume they have understood its behavior for most scenarios. Unlike common deterministic and even some probabilistic systems, where behavior boundaries are well behaved, there could be discontinuities in 'rarer' seen parts of the boundary. And these 'rarer' parts need not be obvious to us humans, since few pixel changes might cause wrinkles.
*vocabulary use is for a broad stroke explanation.
> When the light turned green, the Nissan Sentra and the AV entered the intersection. Against a red light, a pedestrian entered the crosswalk on the opposite side of Market Street across from the vehicles, passed completely through the AV’s lane of travel, then stopped mid-crosswalk in front of the Nissan Sentra.
I wonder whether this flagged alarms in Cruise's systems when the pedestrian crossed in a potentially dangerous situation. These kind of 2nd and 3rd order conditions seems particularly hard to train for.
This sort of thing happens all the time in SF. There are a lot of crazy people in some areas of the city. If you stopped for every one of them (even the ones a lane or two away) you’d never get anywhere. Heck, I’ve had someone run in front of my vehicle, then pull out a collapsible baton and try to rob me. I pinned the throttle and they jumped out of the way.
Is there anything here to train for? The initial collision wasn't in any way Cruise vehicle's fault; but the subsequent repositioning shows their procedures and sensor coverage are lacking. Oh, and their integrity.
Yes, if a pedestrian is crossing against the light in front of you, you slow down even if you don’t think you’ll hit them, even if they’re already past your lane. If the pedestrian stops on the street they are crossing against the light, you slow down, even if they aren’t in your path, especially if you are aware of the vehicles around you and know the pedestrian is in the path of another nearby vehicle. If you see the vehicle in the lane next to you speeding up when you’ve noticed the pedestrian is stopped in their lane of traffic, you slow down and maybe veer away if possible. If you see that the vehicle next to you has hit a pedestrian, you immediately hit the brakes rather than wait 2.4 seconds until you’ve determined you’re going to hit that pedestrian before you decide to hit your brakes.
Those are all things an alert human driver should be ready and able to do. I would expect a quality AV system to do them better than a human, but in this case, none of those things appeared to happen. This AV decided “pedestrian is out of my lane, continue accelerating!” Only stopping when the pedestrian was right in front of the vehicle.
> This AV decided “pedestrian is out of my lane, continue accelerating!”
That's what human drivers do too. If you slowed down anticipating that a pedestrian's collision with some other car might fling their body in front of your car, you'd never make it to your destination. There's just too many crazy people in SF
Cruise isn't at fault for the collision with pedestrian, since it was a second order impact. The primary cause being Nissan Sentra and pedestrian. But could cruise avoided the impact and is this how humans react when we drive? Here is the timeline from the report.
- AV starts moving at -9.2s, after light changes
- Prediction output shows pedestrian path crossing AV travel lane: -7.7s
- Pedestrian leaves AV's travel lane: -5.3s
- Pedestrian pauses at crosswalk : -4.7s
- Contact b/w Nissan and Pedestrian; -2.7s
Yes, this seems to be one of the issues. Here is a talk by ISRO Chairman S Somanath at Indian Institute of Science (IISc) about the same and what they added. He goes into details of what went wrong. These are based on my limited understanding. One of the thrusters had an issue and got activated for longer (or may be activation profile of thrusters at its extreme's were different from modeled). They had a narrow landing region selected as final position (even one possible point). So now their control system tried to correct this but the algorithm had a bug and that caused it to be further delayed. At this point the correction required, i.e; thrusters to be activated, was outside the tolerance levels. So finally ended up with 50m/s vertical speed. https://www.youtube.com/watch?v=fZ2sNRP1opY&t=1440s
With new one, they did couple of things. Larger area to be selected for landing based on camera input. Escape sequence to more achievable points, if something like this happens again. They increased the tolerance from 10 degrees to 25 degrees and guessing fixed the bug in code. They also did some smoothening of the trajectory for different phases to make it more continuous. I think they also made other changes in engines among other things and a whole host of testing.
My bg: Grown engineering teams from 1 person to 20-25 strong and have done this 3 times at various early stage startups. So you know can judge whether this might apply or not.
Depends on people: Are they task oriented / goal oriented ? You can detect based on how they talk about previous projects. Do they say they did x, y, z or do they talk about the big picture of the problem being solved, why they chose what they chose, its features/lack of features etc.
1. Task oriented folks want detailed action items and they don't mind you being super specific. With these folks, have a detailed plan of what to implement, how to implement, break it down into day by day plan. Try to be aggressive w.r.t goals (don't do this, if they are already demotivated), goals that are slightly harder to reach. But ensure that even if they are 60% is done, you will get a workable soln. Ensure that each days tasks are done and checked off and you can track daily progress. Catch up for detailed meetings every 3-4 days. This would be rescheduling of tasks, addition/removal of specific tasks that are no longer valid/requires to be done, re-prioritization/reorganization of tasks etc.
2. Goal oriented folks would want you to give them the vision and overall direction. But watch out for digression that lead to long discussions during such meetings. Tell them what you want to build and why you want to build that, how will the user use it. Then they will figure it out and you can have review meetings. They would not like to you put detailed line by line plans. Ensure you have high alignment during stand-up. Have check ins every 2-3 days to ensure that they are not going in completely wrong directions and you couldn't catch it due to brevity of scrum. But these are usually shorter meetings.
TartanSense Robotics | Computer Vision/Machine Learning Engineers, Robotics Engineers, Full Stack Developer | Full Time | Bangalore, India | On-Site
Tartan Sense is building small robots that can help farmers with various time consuming manual tasks. From weeding, to sowing and more. Farmers struggle with unpredictable availability of labor, low yields compounded with pesticides/herbicides that are often quite harmful. We want to help change that by a combination of precision agriculture, predictable availability and insights for farmers. If you have deep skills in one of the above areas, email us at info@tartansense.com. Please use subject of email as HN | <ROLE> . If you are looking to spend some time in India, in a startup doing interesting and important work, you are most welcome to join us.
Technically, it could be 2.5T because they never say annually. So may be they are talking about 100 years :|. That said, the QZ title is really misleading and click-baity. They have a simulated environment test and yet to tested for real world conditions.
Here is what I discovered in my experience if this helps someone, completely anecdotal.
Paper vs Computer
1. Paper:
- Ability to spread things out, to take stock of a big project, simultaneous refer back, draw between two pages etc.
- Faster draw diagrams etc, partially fixed, see article about thing student who used latex/inkscape to draw.
- Faster to connect up different ideas.
2. Computer:
- Search: When I need to go back to find that idea ('keyword'), when you have hundreds of sheets is super easy.
- Faster to type.
- Easier to organize, I just copy paste and create folders etc. I use Latex and org-mode.
Few Tips
1. Cornell'esque techniques definitely help when revising and organizing.
2. Taking some notes actually helps you to focus better. Reduces random day dreaming, skipping crucial info (which leads to rest of lecture/meeting being harder to understand) etc.
3. Take condensed notes gives me time to listen and makes short notes.
4. But especially in Math related areas, there is no way to assimilate information in one sitting. I often used to hear a random English sentence, only to later realize that some word there had a specific mathematical meaning and it had much deeper meaning than I initially understood. Over-simplified example, xyz is a group. Group here being group theoretic group.
5. Video Recordings of classes and reviewing them and then scribing watching the videos helps a lot, esp for the likes of Advanced CS/EE courses.
6. Writing is learning, verification and long term information storage at the same time. One of my advisors once told me, when I asked him how do you store so much information about various papers etc, "Thats why I wrote that book".
