Robotics Simulation

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

2. 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?

3. 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

4. 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.

5. 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.

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

7. 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..

8. 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

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

10. 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

11. 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.

12. 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

13. 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

14. 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.

15. 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.

16. 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]’

17. 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

18. Skynet v.1b DEMONSTRATION

19. 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

20. 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

21. 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!

22. Thank you! Questions?