Proof of Concept Robotic Drone Referee

Description here

Use Case - Referee Ball Crossing Pitch Border Line

As a proof of concept, part of the system architecture is developed for a specific use case. I.e. to referee a ball crossing the pitch border lines. Given limited hardware and time for development, requirements are relaxed as follows:

• There is no distinction between goal lines and back and front lines. For the demo the developed system does not distinguish between a goal score and a ball crossing the back line. A ball crossing the back line is therefor considered as a candidate for both ball out of pitch and goal score. Additional screening is required to distinguish between these.

• For the demo, there is not aimed for a real-time refereeing solution. Using limited processing power (PC), the aim is rather to proof the concept.

• Ball crossing line is only detected for:
  
  
  • Speeds lower than 1.3 [m/s]. Design Choices:
    • Relaxed accuracy of 0.13 [m]. In the worst case, the ball crosses the pitch line at maximum speed, only just entirely and then is kicked/returned back into the field immediately after. To observe this, ball detection should be possible before and after line crossing. Therefore, at least an accuracy equal to the ball diameter is necessary i.e.: 0.13 [m].
    • Camera rate up to 10 [fps]: To improve simulation runtime the camera frame rate it.
      Getting an accuracy of 0.13 [m] with 10 [fps] results into an allowed ball speed of: 0.13 [m]*10[fps] = 1.3 [m/s]. Ball speed is typically higher than 1.3 [m/s]. For instance in RoboCup matches, ball speeds of up to 10 [m/s] are very common. In actual matches, ball speeds are up to 35 [m/s]. For more accurate ball detection:
      • A higher framerate is required, i.e. higher quality cameras.
      • And more processing power is necessary.
        
        
  • Ball lower than 0.1 [m] w.r.t. the ground. Design Choices:
    • To prevent misdetection (of other smaller or bigger circular objects compared to the ball) a specific aspect ratio is set to search for the ball.
    • The drone height w.r.t. the ground is kept constant at 2 [m]. The aim is to keep the drone as high as possible to increase its field of vision and in such a way be less demanding on tracking the ball and thus motion control. In the test field a net is cast on a height of 3 [m]. To keep from this, a safety margin of 1 [m] is chosen.
      With a specific constant tight aspect ratio and a preset constant drone height, detection of the ball is achievable for ball height up to 0.1 [m]. As a result there is not aimed at detecting/ refereeing ball bouncing across pitch line.
      
      
  • For occlusion less than 50 %. Design choices:
    • The color detection algorithm used for ball detection detects the ball for occlusion up to 50 %.
      The designed system only allows for occlusion under 50%. This is considered sufficient, because in case a better vision is required, the drone has the option to move around to reduce occlusion.
      
      

• The developed system is tested without robots on the field. Robustness against such disturbances should in the future be investigated and possibly improved upon.

Scope realized System Architecture for POC

Considering the time available for realization to proof the concept, the scope is defined as follows:

1. WM – Trilateration
2. WM – Computer Vision
3. WM – Field Line Estimator
4. AS – Rule Evaluation
5. ES – Detection

These are the blocks that have been actually realized, integrated and implemented to test and proof the concept according to the defined use case.
Next to these blocks, some others have been researched extensively:

1. WM – Grid based coordinates
2. WM – Sensor Fusion

Additionally, some have been researched roughly:

1. AS – Search for ball
2. ES – Positioning
3. ES – Trajectory planning
4. ES – Motion Control

Specification Interfaces

Text

Developed Blocks

Developed Blocks