RoboCup Software 2009
From GT RoboJackets
Contents |
Overview
RoboCup Software encompasses all parts of the system that run on a host machine (not the robots). The entire software system is composed of both the components we play soccer and compete with as well as a sort of SDK that allows new components to be written quickly for idea and system testing.
Systems
This describes the various software components. This is not necessarily a development organization, only a logical one.
Standalone
These are standalone systems that can be run without being integrated into a parent framework or environment.
- Soccer
- Soccer Engine. Instantiates modules and gameplay.
- Simulator
- Soccer Simulator. Simulates a game environment as well as the vision and radio components
- Vision
- Global Vision used to identify and locate robots.
- Referee
- SSL Referee
- Radio
- Radio communication with on-field robots
- Log Player
- GUI frontend for the logging module. Playback of logged data
- Motion Test App
- App for testing low-level motion control and hardware drive capabilities
Modules
Modules are components that cannot be run immediately on their own and require a framework to support their needs.
- World Modeling
- Develops models of the world based on available information from multiple systems
- Soccer
- Plays and Behaviors. Play selection and behavior definitions.
- Motion
- Low level robot planning and motion control
- Logger
- data logging module
Frameworks
Frameworks are the glue for modules. They define how modules can share data with other modules as well as how a typical module can operate. Frameworks also provide common code which various modules can use.
Common, Utils, and Config
Amongst all parts of system there are some common pieces of code that are used
- Config File
- Contains system data that doesn't vary between matches but rather between hardware and environment
- Module Development
- Information about writing a module for the system
Architecture
Development
To get started with development, take a look at the RoboCup Bazaar Guide
Identification
There are three forms of identification
- Shell
- A unique number is assigned to each shell [0...15]
- Assembly/Board
- An entire robot is composed of the electronics and the mechanical base. This assembly takes the ID of the board under which it is controlled
- Player
- Software only number for the player [0...4]
- Vision maps from Image -> Shell
- World Model maps from Shell -> Player
- Radio maps from Player -> Assembly/Board
Calibration
- Calibration is identified by the Assembly/Board that was calibrated.
- Invalidated when any part of the Assembly/Board are changed or disassembled.
- This includes swapping electronics, as kicking/chipping calibration may be wrong after that
Plans
- Parameter extraction and estimation
- Ability to switch which side of field
- Burn-in tests/stress
- World model/Data filtering/prediction
- Probabilistic sensing
- Integration/communication
- Timing/Profiling of how our system works
- Motion control
- Analysis of Current Position Controller
- Calibration
- SW test for hardware performance
- Use tech challenges as a springboard
Tasks
List of small project based tasks to be completed
- Write new Referee program
- Develop a control loop debugging app and possible auto-tune procedure
Fixes
- (Stop and Halt) should cause new play selection
- Rework STP architecture, skills = tactics
Notes
- fast loop and slow loop (need to add in framework) (separate threads)
- slow is triggered by something, gets copy of data, runs for indeterminate amount of time, needs to give data to planning so that it gets used on the next frame (double buffer like)
- whatever uses the output of gameplay is holding a mutex the whole time it does processes, thus gameplay cannot change motion commands while motion control is running...this prevents gameplay from running while motion control is running. This makes data copied when it gets copied
- mutex is held only to copy data
