Postmortem

Post date: Feb 1, 2011 9:34:13 PM

Good stuff

• All three teams assembled working robots from scratch and demonstrated some sort of closed-loop or reactive control (wall following, maintaining constant depth, random bounce).
• There was diversity of mechanical construction.
• Until 5:00 am on the morning of the competition, there were no electronics failures. This includes active electronics and (waterproof) connectors. (The only failure was likely due to the absence of the required protection diode across the solenoid actuator. The early morning of the competition was the first time the solenoid had been activated under software control.)
• Hammond electronics enclosures that claim to be watertight are indeed watertight.
• Souriau waterproof connectors are indeed waterproof, if the mounting holes are made carefully.
• Some participants learned soldering.
• The basic Arduino system is simple to set up and works well, but it is limiting.
• All participants were exposed to the concepts of behavior-based programming, though not everyone had time to program actual behaviors mediated by an arbiter.
• All participants began to think in terms of concurrent processing — threads.
• Except for the limitations imposed by the C preprocessor, the capabilities of the Protothreads library are more than sufficient to enable behavior-based programming.
• One participant was able to experience the power of real-time data plotting.
• Real-time control, even limited to a command-line interpreter to set variable values, is a powerful tool.
• Tethered operation is essential to development, as it allows monitoring of the robot’s sensors in real-time, as well as direct control of the actuators for testing purposes.
• With adequate illumination, the Avago color sensor worked underwater, but not from a great distance.
• The Sharp distance sensors worked underwater.

Stuff we can improve on

• We need to complete the development, testing, and documentation of a robust electronics and software platform well before IAP begins.
• We need to complete the development of course materials (introduction to building submarines, introduction to electronics and software control, principles of behavior-based programming, specifics of the particular software platform, etc.) well before IAP begins.
• OtterBoxes may be waterproof, but they are not truly transparent.
• Pelican cases may be transparent, but they are not really watertight.
• Machining the holes for connectors is non-trivial, and a poor job leads to leaks.
• Neither the Edgerton Lab (4-409) nor the MRT space (N52-318) are equipped to do serious electronics construction or assembly.
• Much of the electronics assembly was not done by the individual student teams.
• We could use real-time reporting of the state of battery charge — or at least its voltage. Robot behavior becomes unreliable when battery voltage falls too low, and this confuses the debugging process.
• Waiting for the battery to recharge slows down development. Ideally it would be possible to swap batteries without opening the main electronics enclosure.
• The Arduino serial library was unreliable under certain conditions, causing us to chase false bugs; this needs investigation and correction.
• As a consequence of problems in the Arduino serial library, the simple command-line “control console” could not be used with full effectiveness.
• Because of limitations in the C preprocessor and the tricks of the Protothreads implementation, the Protothreads macros could not be called from within other macros.
• Setting up cygwin and gnuplot for everyone would have been too labor intense. We need better tools (a turnkey solution) for data monitoring and plotting.
• Arduino tries to make C programming easier, but once you add a library for behavior-based programming, you want out of the IDE.
• Perhaps the ideal language for beginning roboticists would be an interpreted one. What standard language would be a good choice? (Examples of commonly interpreted languages are Lisp and Python.)
• Managing the tether is difficult: we needed t0 unplug it frequently so that the cable could relax and untwist. It would be great to have a rotating electrical connector. One example is this 6-pin rotating connector from Mercotac that does not use slip rings (no brushes). Another possibility for data transmission is a fiber-optic rotary joint like these from Moog.

— Daniel Ozick

Student Discussion

On Monday evening, January 31, 2011, a number of the students who had participated in MRT IAP 2011 gathered to talk about their experience. Present were

• Richard Dahan, President of MRT
• Ed Moriarty, Edgerton Center Staff
• Daniel Ozick, MRT mentor for IAP
• Yazan
• Jackie
• David
• John
• Alexis

Here are some of the comments made and questions raised, in the approximate order in which they occurred:

• There was not enough time to complete the project.
• The electronics were late.
• One of the teams wasn’t aware of the size of the battery in advance.
• The block diagram of the electronics system was helpful.
• We needed more time to test.
• Prior examples of working vehicles would be helpful. This year’s vehicles can help next year’s participants.
• 6.270 spends $1500 per robot. (Ed said that for the MRT vehicles, that would be killing an ant with a sledgehammer.)
• We should advertise through the “Discover OE” program.
• If you want to learn serious robotics, participate in Maslab.
• Systems integration is hard.
• Should there be a standard kit of materials?
• Which aspects of design should be open to student creativity? Only mechanical and software design, or electronics as well?
• What about several styles or options?
• The course needs a textbook that everyone gets.
• Don’t reinvent the wheel — check out what 6.270 does.
• How many students should particpate? 15? 50? (Ed recommends that the size of the group not exceed 24 students. That gives you 8 groups of 3 or 6 groups of 4.)
• We need teaching assistants.
• The competition provided a reasonable level of complexity.
• The arena should be bigger.
• The competition should include 3D elements — change the depth of the “pipe.”
• Make it so no team can complete the entire competition.
• Have more colors on the floor.
• Use IR beacons to define the arena in a section of the swimming pool.
• You should have to defend each step of your design to a T.A. There should be milestones, checkpoints, intermediate goals.
• Mentors should have a schedule and students could sign up for lab time with a particular mentor.
• Teams of three are good, because you have a tiebreaker with regard to design decisions.
• Teams of three are good, because if one person doesn’t show up, you aren’t alone.
• Is the primary goal community building, or is it about teaching content?
• Who is the target audience? Should it be mostly freshman? What can you expect freshman to know?
• You could have participants fill out a questionnaire to determine their knowledge and skill levels in advance.
• Should teams be randomly assigned, or should students get to choose? Diversity of skills? Old friends? New friends?
• Focus on the competition itself (with real rules and prizes) to motivate learning and attendance at lectures.
• Ed talked about the need for standards for software revision control and naming conventions. Even students who might be good programmers may not be aware of good practices in this regard.
• We should have a big binder with all the documentation and recommended procedures for an orderly development process.
• We should get more advance warning on the requirement to make presentations.
• Knowing that you have to defend your design decisions in a presentation motivates better designs.
• Keep the behavior-based approach, as it differentiates this course from others.
• Everyone had fun despite the frustrations.
• The best part was seeing the robot come “alive” and react to its environment. That was much more fun than scripted robot commands.