HN user

sumodm

149 karma
Posts5
Comments15
View on HN

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.

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

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.

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.

Two cents:

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.

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".

First point is really important. I can give email addresses to 100 people in India and ask them to message an important medical information (something of high value to recipient and no value to this person, at negligible effort) and the conversion would be quite low. Email for unacquainted users is perceived to be hard. Large part of India and other developing countries became digital without going through the internet of 90s and early 2000s. So email is foreign to large mass of people.

Digital Aristotle | Backend Dev, Frontend Dev, ML/NLP Lead | Full-time | Bangalore, India

We are in the process of building an assessment to remediation- analytics platform that aims at redefining the way Schools conducts Assessments. ​This platform lets teachers easily set question papers, correct them, and generate instant meaningful reports. The tool covers Mathematics, Environmental Studies, Science and English across grades 3- 10. The objective is to provide students with a continuous evaluation, showcase their strengths and interests and also empower both parents and teachers with insightful reports.

Requisites

- Frontend: Angular, HTML5/CSS (4+ years exp)

- Backend/Full Stack: NodeJS, NoSQL, Functional Programming Experience (Erlang/Haskell) (4+ yrs exp)

- ML/NLP Lead: Experience delivering products + Strong Natural Language Processing, Machine Learning, (In depth knowledge of Programming Language Theory / Computer Vision / Graph Theory are great). Solid Math/Algo/Data Structures background is must.

- Wisdom to know when to hustle and when to be calm and dig deep. Strong can do mentality, someone who wants to join us to build on a vision, not to do a job.

contact: 'sum + od' at digitalaristotle.ai (remove the + :)

My 2 cents 1. You don't need a Ph.D to build a product that uses DL/ML. Some part of your work here could be to define the problem and to understand how to phrase the problem so that it is solvable (if its too easy, your moat won't be technological). Your contribution here could be applying deep learning to new applications. Specifically for applying DL in industry, someone with ability to quickly tryout a lot of things is a good thing to have (with some amount of self-discipline). 2. You don't need a Ph.D to be part of a team that is taking on a hard DL/ML problem. You will hopefully have leaders who can set the directions. 3. Ph.D like most degrees is a label. If you can develop the skills of a good researcher (like any other craftsman), learning to comprehend research ideas quickly, keeping tab of interesting ideas and recent progress, then one could easily find connections and even publish good papers. 4. Now if you really want to understand what happens deep down, why does DL work, to understand how it could be viewed as Tensor Decomposition or coming up with new mathematical optimization or drawing a new connection between sub-areas: then having dedicated time to build those skill-sets (aka Ph.D) is very helpful.

Soliton Technologies - www.solitontech.com - Bangalore, India - ONSITE

Soliton invites applications for an R&D Software Engineer/Lead in a group specializing in Computer Vision and Machine Learning. Recent projects have included obstacle detection on mobile platforms, object detection/classification and 3D reconstruction. We are looking for exceptional candidates who have a sense of ownership and have the necessary grit to make successful research products. The candidate must have good understanding of basic mathematics (linear algebra, statistics, probability and good understanding of fundamentals of computing (Algorithms, Data Structure, OS Fundamentals). The ideal candidate will also have strong development skills on nix platform and ability to prototype very quickly.

Required Skill sets* • Good understanding of Image Processing and Computer Vision with projects to back the same • Strong programming experience in C++ • Knowledge of at least one prototyping/scripting language : Python, MATLAB/Octave, Julia or R • Good understanding of Algorithms and Data Structures • Good knowledge of basics: Linear Algebra, Probability and Statistics • Good written and verbal communication

Other Openings : Project Lead – Web Technologies (Node.JS/Angular.JS) • Lead a highly talented team of 10 people • Set and meet high standards of excellence in the quality and timeliness of the software delivered and achieve customer delight • Ensure that the defined processes are adhered to; and contribute to the development of these processes by sharing best practices and learning from projects • Empower the team and ensure that the team spirit is high at all times and provide individual mentorship to engineers to help them with career growth

More details here:http://www.solitontech.com/careers

Email your resumes @ careers@solitontech.com