Autonomous Referee System

Autonomous Referee System
'An objective referee for robot soccer'

Introduction

This project was carried out for the second module of the 2016 MSD PDEng program. The team consisted of the following members:

• Tim Verdonschot (Team Leader 1)
• Tuncay Olcer
• Sa Wang
• Joep Wolken
• Akarsh Sinha (Team Leader 2)
• Farzad Mobini
• Jordy Senden

Project Definition

As described in verbatim, the goal of the present project is to contribute to this vision and create an autonomous robot referee system using drones. The first generation of MSD PDEng students created a system architecture to be used with a single drone. This architecture provides the basis for the present project. In particular some of the modules of such architecture, such as out of bound ball detection and an indoor positioning system using ultra-wind band technology, were implemented and tested. The overall goal of this project is to extend this system architecture and implement more modules.

Background

A drone referee may provide several advantages with respect to a human referee or a camera based system covering the entire field. First, human referees, naturally prone to human errors, are one the main causes of controversy in the game; they have their own interpretation of the rules, introducing a non-predictable factor often leading to unfair situations in a game where both financial and emotion stakes are high. An autonomous system would mitigate this, and in particular remove the unfairness factor - every game would be refereed according to the same algorithm.

Project Objectives

• System architecture of the proposed solution by January 31st along with a time plan, risk assessment of the choices, and task distribution for the elements of the group.
• Software of the proposed solutions including:
  • Out of bound ball detection by the ground robot, including both motion algorithm and camera processing. Suggested: end of January.
  • Detection of a fault including both movement. Suggested: end of February.

• Software with the interaction between the two robots. Suggested: end of March.
• Demo to be scheduled by the end of March or beginning of April.
• A Wiki-page documenting the project and providing a repository for the software developed, similar to the one obtained from the first generation of MSD students.
• One minute long video to be used in presentations illustrating the work.

Literature survey and background work

Definition of fault/foul

The definition of foul/fault or offence is based on the Robo Cup MSL Rule Book . Simple physical contact does not represent an offence. Speed and impact of physical contact shall be used to define offence or a foul. There are two cases in which foul detection should be formulated.

• Case 1: One of the robots is in possession of the ball

• • A foul will be defined in this case if Robot B impedes the progress of the opponent by
    1. Colliding after charging at A with v unit velocity
    2. Applying (instantaneous) pushing with ≥ 𝑭 unit force
    3. Continuing to push for time ≥ t seconds
    4. Knocking the ball off A by sudden (Instantaneous) application of force (≥ 𝑭 unit force)
• Possible ways of measuring these
  • • Velocity
    1. Visual odometry (Image-based Object Velocity Estimation)
    • Application of (instantaneous) force
    1. Use visual odometry and calculate velocity/ acceleration and include time data.
    2. Estimate force accordingly
  • Continuous push (B is pushing A)
    1. Detect instantaneous application of F unit force
    2. Detect if B changes direction of movement within t seconds
  • Knocking off ball (only visual data)
    1. Detect collision
    2. Detect ball and Player A after collision

• Case 2: None of the robots are in possession of the ball

• • A foul will be defined in this case if Robot either A or B impedes the progress of the opponent by
    1. Colliding with larger momentum (say, pB ≥ pA units)
    2. Continues with the momentum the for time ≥ t seconds (dp/dt=0,for t seconds after impact)
  • Possible ways of measuring these
    • Momentum
      1. Use visual odometry to estimate velocity (and elapsed time)
      2. Estimate momentum accordingly
    • Continuous application of momentum
      1. Detect if defaulter changes direction of movement within t seconds