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?