Robotics Simulation (Skynet) Andrew Townsend Advisor: Professor Grant Braught

Introduction Robotics is a quickly emerging field in today’s array of technology Robots are expensive, and each robot’s method of control is different Used in Dickinson College’s Artificial Life class dLife – universal robotics controller Problem to be solved: How can multiple students do coursework for the Artificial Life class at the same time?

Three Critical Goals for the Solution Accurate modeling of Hemisson and AIBO robots Multiple simultaneous users controlling multiple robots at once Solution must integrate with the existing dLife package

Proposed Solution Simulation provides a cheap alternative software solution to this problem. Many Robotics simulators already exist Not all simulate multiple robots or accept multiple users None of them integrate with dLife.

Robotics Simulator’s Role Integrate transparently with dLife such that the process of using a virtual robot is the same as using a physical robot Provide support for multiple users using multiple robots in the same ‘space’ Accurate modeling of a robot’s expected actions, to provide an effective alternative for Artificial Life students.

Background Several robotics simulators already exist Some of these include Pyro, Gazebo, Stage, Simulator Bob, and SIMpact

Background.Pyro Pyro is one of the most similar applications to dLife. Concentrates on providing a single language to communicate with a robot so that the user does not have to learn a new language for each kind of robot Integrates with another simulator called Stage..

Background.Stage Closest to this project Integrates with client packages, such as Pyro Focuses on representing a world and the simulated robot’s interactions with that world

Architecture Similar to the Pyro/Stage methodology Client / Server Architecture Communication should not be limited to the local machine Use Socket-based communication.

Architecture.Client (dLife) The client of a robotics simulation represents a user’s input to the robot dLife already provides a unified interface to abstract the user’s control of the robot and relevant sensor readings, regardless of what kind of robot it is dLife must simply be extended to allow for socket based communication, rather than using serial communication. Other than connection mechanisms, all other processes should be essentially identical to dLife’s interaction with a physical robot

Architecture.Server Most obvious choice is to use Java Server must be able to simulate the robots while still accepting new connections. Threaded connection listening! Server has two main roles: Server must be able to accept some form of predefined world, and display it to the user. Server must also be capable of modeling a robot’s actions in that world.

The World is what you make of it Clearly a simulator is useless if you can’t see what the robot is doing Worlds are created from reading input from text files. World Files assume ‘real world’ dimensions, in this case meters, and translate from there. Axis flip

The World File Each World File contains basic information such as the dimensions of the world and coloring. Also allows for a SCALE statement for perspective purposes Each world file can contain an unlimited number (barring system resources) of objects that reside in the world

The World File: Objectivity Objects are currently limited to circles, rectangles, and lines Objects are defined in the World File by their size, position, and coloring. Currently objects are impassable objects as far as the robot is concerned, but moveable objects are a possibility for the future.

The World File: Syntax Checking Upon loading a given World File, the server checks the file against the expected format and reports errors intelligently. Erroneous data is reported to the user and discarded.

Robot Modeling.Representation Each kind of robot should be drawn in the same way, with slight variations to indicate which robot is which. Currently, only the Hemisson robot is implemented, and is represented by a circle of the user’s choice in color, with a line pointing in the direction the robot is facing. Server handshake: ‘Hemisson [x] [y] [direction] [color]’

Robot Modeling.Implementation As each robot is meant to be independent of each other, robots are implemented as versions of the robotThread class. Thread is associated with the socket connection, real-time communication. All processes associated with that particular robot are handled exclusively in that thread. Makes it easy to keep each kind of robot’s appearances, capabilities, and actions separate while still keeping it easy to add new kinds of robots to the mix. Timing is everything

Skynet v.1b DEMONSTRATION

Status World representation is essentially complete dLife integration is complete except for one thing… Robot representation is defined and almost entirely complete, but problems with directional values (rounding errors and conversion issues) Collision algorithm only partially works Only forward/backward movement is fully supported, although command parsing is implemented

Challenges GUIs. Keeping real world measurements separate from internal ‘backend’ measurements. Directional values are more elusive than they should be. Writing code in such a way that test cases would work (more threading!) Collision detection algorithm

Future Work Mostly revolve around the “HemissonThread” class Independent and different wheel speeds Fix directional value calculations Empirical testing for accurate modeling – tweak timer accordingly Fix dLife dialog box. Finishing collision detection algorithm Add support for scripting? Bring the noise Implementation of simAIBOs!

Thank you! Questions?