Modification history:

Team Members:

• Jeff Goodman (Jeff2379@aol.com)
• Jeff Miller (J_Miller68@hotmail.com)
• Michael Wales (Mag7Rule@aol.com)

Contents of this Document

The Current System

The Proposed System

• Needs
• Users and Modes of Operation
• Operational Scenarios
• Operational Features
• Expected Impacts
• Analysis

Currently, when humans and simulations interact, they do so close to the computer's domain. Some of the most "free" systems we have seen involve a human with many wireless devices attached to him, and in a very small controlled environment. STRICOM, IST, and SEECS are looking for ways to bring the interactions between military software simulators and human actors more toward a natural real-life environment.

STRICOM currently has a simulation system where a human participant can interact with a DISAF (Dismounted Infantry Semi-Automated Forces) simulation through a variety of virtual reality gear. The human wears a HMD (Head Mounted Display) to get a virtual viewpoint of the simulation world. The HMD gets a wireless NTSC video feed from a VGA-to-TV converter box, and a wireless video transmitter device. The user carries a small directional controller for movement either on his rifle, or on his belt that wirelessly transmits joystick controls to the simulation computers. The human participant can also carry a hands-free microphone that is wirelessly connected to a computer that accepts voice commands to control some of the friendly simulated entities. The user also wears a suit with light sensitive sensors that are monitored through a 4-point camera tracking system so the simulation can know the exact point in space of the humans various limbs and body parts. This data that is also used by software that recognizes gesture inputs from the simulant to interact with the simulation.

There are many advantages and disadvantages to STRICOM's system. The good part is that human simulants can interact with the simulation in totally different geographic locations through the Internet. Some humans will interact with simply a joystick and monitor, while others can use the VR gear. The VR gear is very bulky to wear, it tends to get quite warm, and the HMD unit is fairly glitchy. Many soldiers get sick using the VR gear.

STRICOM is looking to create a new type of simulation system where human participants can train in simulated scenarios, by interacting with computer controlled simulation entities. This will be a very large project that will be developed in the following several years. Our senior design project will focus on finding a solution to the task of establishing communication between a robotic device and a software simulation. We are going to create a software interface for a simulation to implement that will control a robot. We will also create a surrogate system that will mimic the activities of a robot for testing purposes.

Simulation software: The simulation software is going to be the primary user of our software in the final design of the simulation system. The simulation will be provided a simple interface that will allow it to communicate a various number of ways with a robotic device.

Human Robot Controller User: A human will be able to gain direct control of the robot and use a joystick to dictate the robot movements. This mode will be useful if the simulation administrators feel that the robot might be malfunctioning. This mode does not require the simulation system.

Simulation Programmers: Programmers will have help interacting with robots in the development cycle through the use of the robot surrogate. An application will mimic robot activities, and can be used to test the simulation's control of the robot without actually having a robot present.

Simulation: A troop of soldiers is on a training mission to stealthily take control of a communications building in a remote area behind enemy lines. As they approach the building, the small troop hears an approaching vehicle. The soldiers take appropriate cover to not seen by the surveillance. In previous training missions, the soldiers failed to react quickly enough, and they were spotted ending the chances for a successful mission. The vehicle is controlled by the simulation system and has motion and heat sensing sensors on it, but no humans. This time, the soldiers have evaded the vehicle's detection and proceed to capture the building successfully.

Human control of robot: A toxic chemical has been spilled in an industrial facility. A team of simulated robots is used to clean up the spill that would be dangerous for humans. Unfortunately, the simulator has gotten one of the robots stuck. A human takes control of one of the other robots and pushes the stuck robot from off the obstacle it was stuck on. All control was done remotely through a laptop outside of the building. The human user then turns control of the robot back over the simulation so that it can continue cleaning efforts.

Robot Surrogate: A team of developers is working on implementing the robot controller software into their simulation testbed software that they have just developed. They do not have a robot to test their software on, so instead they use an extra PC to run the robot surrogate software. The developers can then view the messages their software is sending to the robot surrogate on the surrogate's screen.

Must Have:

• Robot Controller
  • OTB interface
  • Joystick interface
  • Communication interfaces
  • Move Control
• Robot Surrogate
  • Communication interfaces
  • Move protocols which allow controller to move the surrogate

Would Like to Have:

• Actual Robot
• Simulation software implementing Robot Controller
• Demonstration of simulation controlled robot

Our project is going to be the stepping stone towards new research and development in the simulation field. It will allow human control of a simulated robot and if time allows a real robot. Our system will also allow for computer control of the robot through OTB software. Humans will have real world interaction with a computer simulation, which will lead to better training. Our system will also save money since the user can simulate a robot instead of having to actually purchase a robot before they know what kind of robot they actually need.

Expected Improvements: No system currently

Disadvantages:

• Language: The system will not be portable because it is being developed in C++

Limitations:

• Time: The project must be completed by late July 2001 or we will not graduate

Risks:

• Time: As an undergraduate in our final two semesters our course load is heavy. We must make every attempt at keeping on our timeline for this project.
• Experience: We have no experience in developing applications that use devices such as a joystick. We also have little experience with networking and no experience with XWindows GUI's
• Computer Availability: We may not have enough access time to the particular computing environment that we require to develop this project

Alternatives and Tradeoffs:

• Language: We could develop the program using Java, which would make the program portable. We also have experience with networking and GUI development in Java.
• Computer Availability: Developing the product in Java would also take care of our computer availability problem. By using Java the program could be developed on a Windows platform and easily ported to a UNIX / Linux platform.

This page last modified by Michael Wales (Mag7Rule@aol.com) on March 23, 2001.