1 / 22

Robotics Simulation

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

xaria
Download Presentation

Robotics Simulation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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?

More Related