Contingency Plan

Last semester brought about a real issue with our project. What happens if our robot breaks or is no longer available for our use? Would our group have to wait another semester to finish our project or are there alternatives? In order to prevent a repeat of this course some measures must be taken in the case that our robot would fail. These “options” will be listed in order of their likelihood.

Option A

The university owns two little robots that are practically identical. We would easily be able to move from using the robot we currently have to the other little robot. The only difference between the two is the camera. Of course, there are always some catches when changes to anything in a project occur.

Option A – Problems

As of this semester, CS 490-a mobile robotics class-has started. This class has graciously given us one robot for our project, but they will be using the other for their class. If our robot should break or their robot should break for that matter, we would be forced to share the robot with them. This would hinder our time to test and use the robot. We would have to iron out conflicting times with the 490 class over the usage of the robot. Last on the list of problems is the re-boot problem that had previously occurred.

Option B

Along with the two little robots we own one big robot, called the “peoplebot.” The only major differences are in the physical characteristics.

Option B – Problems

Peoplebot is much taller. Due to its height, peoplebot’s gripper won’t lower to the level we had anticipated in order to grip the chairs. This would pose a problem that we would have to overcome. Also, the camera is much higher. Would it be able to read color tags the same as the smaller robots do? Other issues are stability and height itself. Would the robot fall if it went over a wire cover on the floor? Would the peoplebot hit things that the little robots could pass underneath? Peoplebot has also had a known re-boot problem. These are many of the issues that would need to be dealt with if this option should be used.

Option C

Software is available for the robots to run in a simulated environment. We have used this software to test and run snippets of movement code that we have already done. This could be used to show movement and obstacle avoidance, for instance. With a nice mapping tool we could run a simulation through a map of the room.

Option C – Problems

The simulator would only allow us to demonstrate the movement portions of our code. We could only show free-range motion with obstacle avoidance. These are the only portions of our project that would be viewable leaving out chair finding, gripping, and placement. If this option would be chosen, a lot of the coding for parts would have to rely on explanation of the code only.

Option D

We could film all of our progress, which would give a way of demonstrating our progress. This option could be used as a fail-safe in parallel with all other options. This could be very useful in the case that we finish all portions and all the robots have to be sent back. For this option we would film at least our working code modules in action. When each portion or possible release comes about we would film it as a bookmark, to say we got here before we were stopped.

Option D – Problems

This method of showing a project is not as powerful as the actual thing. The robot moving in front of a group of teachers is much more powerful than a film of what would happen if we actually had the robot. Another ther problem is that we could get more code working that after we no longer have a robot to run for filming it in action. Lastly, it is harder to work a film into presentation because there is more explaining involved than in an actual demonstration.