Stress Relief Video

1. Stress Relief Video

2. Team WPI-CMU and the DARPA Robotics Challenge Chris Atkeson July 9, 2015

3. DARPA Robotics Challenge

4. Day 1

5. 3 Stages • Simulation: VRC; Team Steel -> WPI-CMU • Isolated tasks: DRC Trials, Dec. 2013 • 8 tasks, 30 minutes/task. • Safety belays. • External power. • WPI-CMU: Fastest driving! • Sequence of tasks: DRC Finals, Jun. 2015 • 8 tasks, 1 hour • No safety belays or external power • Simplified Trials tasks: • no hose, ladder->stairs, surprise task

6. VRC Team Steel: VRC Was A Disaster • I can’t manage my way out of a paper bag.

7. Team Steel VRC The Crack of Doom Chris Atkeson

8. VRC Add Safety Features To Handle User Error • An exhausted and distracted user (me) crashed the robot twice by typing in the wrong command (for example, 0.23 instead of 2.3 for yaw angle).

9. VRC Make Sure Your Safety Features Don’t Kill You • Suicide Bug: A safety feature was added late in the game so if the robot fell, it fell in a way that was easier to recover. • Unfortunately, this feature triggered on false alarms several times in the VRC, causing the robot to fall when nothing was wrong. • We have been unable to reproduce the orientation measurement glitches that caused the false alarms on our own computers. Only testing on VRC computers would have detected it.

10. VRC What we should have done • Start with fully teleoperated systems, and then gradually automate and worry about bandwidth limitations. • Formal code releases • Better interfaces • Periodic group activities that simulated tests or did other things that got people to integrate and test entire systems.

11. VRC Project Management Rules We Violated • Freeze early and test, test, test. • Detect crack of doom bug, • Don’t introduce suicide bug • Resist temptation to tweak • Put in safety features to be robust to tired distracted human users. • Make sure your safety features don’t kill you. Suicide bug was not robust to false alarms. • Don’t have project leader also run a division: lose an overall firefighter and skeptic.

12. VRC Issues That Required Effort • State estimation, particularly with point or edge contact in rough terrain (wobbly foot). • Driver dynamics. • Keep planner from doing stupid things. • We found designing robust behaviors very time consuming. We need better tools. • Integration “API”. How do we specify behavior interconnections?

13. Trials DRC Trials: Schaft video

14. Trials Terrain

15. Trials DARPA Robotics Challenge TrialsWPI-CMU • Challenges • Modeling error • Full-body behavior • Affordability (make cheaper robot) • Accomplishments • Whole body control • Best ladder climbing of Atlas robots • Fastest driving

16. Trials DRC Trials: Failures • Operator error on Drill -> Idiot Proof Interfaces: Minimize interface: no typing, no click boxes or other options, no pop-up menus. … • Wind on Doors -> Practice in a hurricane or wind tunnel (which we did). • Knee torque limit on Terrain (and maybe belay) -> Explore and know robot limits.

17. Trials 3 Classes of Robots • Atlas Robots • Bipeds: SCHAFT, all others • Non-bipeds: CHIMP, RoboSimian

18. Trials Speed • All robots were VERY slow • Perception? • Planning? • Rational? • A lot of the time the robot was not moving

19. Trials Walk and Push • Wind on doors: needed to walk and apply force or hold position at same time.

20. Trials Bump and Go • No one could get out of the car. • Presumably, no one could get into it either. • “Bump, Lean, and Go” locomotion

21. Trials Ladder • Few teams seriously attempted the ladder • The ladder was really steep stairs. If your kinematics matched it, it was a trivial task. • If your kinematics did not match it, it was a whole body locomotion task.

22. Trials Ladder

23. Trials Kinematic Targets • Both rough terrain and the ladder, locomotion were dominated by tight kinematic targets. • Basically these are all stepping stone problems. • This is different from most research on legged locomotion.

24. Trials DRC Trials … • Debris was hard for a lot of teams • Planning? • Perception? • Execution? • Screwing in the hose was hard as well.

25. Trials 2013 Atlas Issues • Kinematic Error – 7cm at foot • Stiction – 20Nm • Knee too weak • Torso (particularly pitch) was not strong enough, lots of kinematic error. • Couldn’t see feet (knees in way). • Hard to see hands (limited neck, occlusion)

26. Trials Secrets of our ladder, walking • Use visual feedback to human operator to guide hand and foot placement. • Use estimated foot location if you can’t actually see your foot. Draw foot on video. • “Nudging” user interface.

27. Trials Challenges for Final • More robust walking: No safety ropes: Never fall down • Robust CMU-manipulate • Get in and out of car • Use railings on ladder: weak arms and hands • Doors: walk while applying force • Debris: pre-plan

28. Trials Optimization All The Way Down • Multi-level optimization: • Optimization-Based Inverse Dynamics: Greedy optimization (QP) for full body at the current instant. • Trajectory Optimization (Continuous across time) • Footstep Optimization (Discrete + continuous across time)

29. Trials Two Level Control • Level 1: External forces at contacts drive center of mass (COM). Rotation is more complicated: • Constant angular momentum • Rigid body equivalent • General case • Level 2: Redundancies and constraints resolved for full body behavior.

30. Trials Level 1: Thinking About The Future • Use simple models. Can we just think about COM, or does angular momentum matter? • LIPM

31. Trials LIPM Trajectory Optimization X vs, Time X vs. Y COM COM Footstep Footstep Y vs. Time COM meters Footstep

32. Level 2: Optimization-Based “Inverse Dynamics” (QP) Trials Stephens Objectives: • Dynamics • Task Objectives • COM Acceleration • Torque About COM • Reference Pose Tracking • Minimize Controls Constraints: • Center of Pressure • Friction Cone • Joint Torque Limits M. de Lasa, I. Mordatch, and A. Hertzmann, “Feature-Based Locomotion Controllers,” ACM Transactions on Graphics, vol. 29, 2010.

33. Trials Optimization? • + Can help you solve complex problems with many factors. • + Skills can be combined during optimization/practice/learning. • - Often hard to choose constraints and weights to get what you really “want”. • - If your tools are slow (need to do a simulation to check things out) this design process is slow. • - Not reliable: similar inputs may lead to very different results. • Use more hard constraints? • Prioritized vs. single-level optimization

34. 1.5 years

35. Finals Watch the DRC Finals!

36. Finals Team WPI-CMU • Did well (14/16 points over 2 days, drill) • Did not fall • Did not require physical human intervention • Tried all tasks (eliminates RoboSimian, which skipped stairs). • Safety code worked. • Operator interface and operators worked. • State estimation, walking, and manipulation core code worked very well.

37. Finals Slow and Steady vs. Fast and Flaky • We knew we were going to be slow • Reliable walk • How we used human operators • Lack of total autonomy plus communications delay. • Strategy: Assume other teams will rush and screw up (which happened). • Assume Atlas repairs will not be possible.

38. Finals Day 2

39. Finals Real Time

40. Finals Walking Manipulation

41. Finals Handling modeling error and external forces

42. Finals Stuck on the door

43. Finals

44. Finals Failed manipulation

45. Finals Fall Predictors

46. Finals A bad step

47. Finals Egress: Maximize Contact

48. Finals Discrete/Continuous OptimizationOffline + Online Optimization

49. Finals 2015 Atlas • New electric forearms add a 7th arm degree of freedom. Huge difference. • Weak, flaky, poorly sensed electric forearms, like T. Rex. • Lower body, torso problems all fixed. • Limited foot sensing Fz, Mx, My but not Fx, Fy, Mz.

50. Finals WPI-CMU vs. IHMC, MIT walks • We were slower (8s stride) but took longer footsteps (0.4m). • Our max speed is 1.6s stride, 0.4m/s • We do gentle steps, IHMC/MIT have shock waves. • We use foot sensor Fz, COP, they only use it as a binary contact sensor. • Was anybody compliant? See fall videos.