1 of 29

MSL Reference Architecture�(MRA)

2 of 29

Why MRA: Hardware standardization efforts and contributions

Hardware

  • TURTLE 5k
  • 4-cam omni-vision Falcons�

Different team, similar hardware

  • Omni-wheels
  • Omni-vision
  • MSL kicker
  • Ball-handling

​

​

​

​

​

​

​

No standard but a lot of commonality in hardware of MSL teams

3 of 29

Why MRA: Software standardization efforts and contributions

Software

  • RTDB – Real-Time DataBase
    • Most teams, different scope
  • Ref box + MSL logging protocol
  • Mixed-Team protocol
    • Falcons, Robotsports
  • Simulator
    • Gazebo based simulator (Nubot)
    • Common Simulator: Tech United
  • ROS/ROS2
    • Used by some of the teams
  • RIF code on Robotsports hardware
    • rsopenapi

​

A new MSL team needs:

- 3-4 years before it can play according MSL rules

- Few more years to become a top team

Other leagues: �- Soccer simulation (SSIM) �- Standard platform league (SPL)

​

Software is published after each RoboCup;�Starting point for the next RoboCup. �(build on top of, stacking innovations)

Limited re-use of software in MSL in last 20 years

4 of 29

MSL Reference Architecture

The 11 published software designs of MSL teams �in 2022 have commonality in the software design.

​

The classic Sense, Think, Act blocks can be divided in

multiple smaller components which can be easier

to share between teams.

​

This is the basis for the MSL Reference Architecture (MRA)

​

MSL workshop 2022 was trigger for kickoff of the inter-team MRA workgroup�

​

​

​

5 of 29

Goals for MSL Reference Architecture

Increasing development speed of MSL teams

​

  • Jump start for new teams
    • Reduce time needed for first game
    • Faster competitive and applying to all the MSL rules

​

  • Reuse proven software parts from each other
    • Focus on own strength instead of doing everything ⇒ more innovation.
    • Increase performance in general ⇒ Balanced games, challenging the top teams

​

6 of 29

Draft design based on 11 MSL SW architectures

Component decomposition

  • 30 general components
  • 8 hardware interfaces

​

​

Refbox Computer

Sideline Computer

World Model

Behavior

Actions

Teammate

Hardware

Design is draft:�actual implementation will define interfaces.

​

7 of 29

Nice theory, but …

how does it work?

8 of 29

MRA components

​

Components are the basis of MRA

​

  • Components have a standardized interface.�
  • Component dependencies need to be managed.�
  • Components are interchangeable.

​

​

9 of 29

MRA aspects

  • A standardized component design
    • Interface
    • Semantics
    • Using protobuf for now�

​

  • MRA repository as marketplace for MRA components�

​

  • Implementation and publish as MRA component

​

10 of 29

RobotSport using MRA::GetBall - First impression

  • Refactor a bit to split behavior in two matching MRA components
    • MRA::GetBall
    • MRA::VelocityControl �
  • Resulted in implicit reviewing current design → bugs found�
  • MRA setup is feasible
    • incremental migration
    • middleware independent

​

Robotsports::MoveToBall

RobotSport::Motion

MRA::Falcons::�GetBall

MRA::Falcons::

VelocityControl

velocity (RCS)

velocity (RCS)

position (FCS)

RobotSport::Motion

11 of 29

MSL Reference Architecture - recommendations

Engagement is needed !!!�

  • Start with discussion platform to define MRA
    • Monthly Discord call
  • Start MRA marketplace to exchange code
    • Add defining documents to discuss
    • Add your own strong components for others to use
    • Pick other components for your own use
  • Embed MRA in MSL community
    • Stimulate participation by getting scoring points

12 of 29

Thank you! Questions?

13 of 29

end – backup slides

14 of 29

Why MRA: MSL status 2014

Strengths

    • Proper benchmark
    • Appealing to audience
    • Long history, large community
    • Highly dynamic
    • Realistic size
    • Focus on robot-robot collaboration

Weakness

    • High start-up costs
    • High participation costs
    • Difficult to catch up for new teams
    • Not all continents represented

Opportunities

    • Document and valorize
    • Sponsor friendly – audience and media
    • Real soccer dimensions

Threats

    • Quitting due to high costs
    • Difficult balance between science, mgt and maintenance
    • Balancing evolution versus revolution
    • Inaccessible to new teams

source: RoboCup MSL - History, Accomplishments, Current Status and Challenges Ahead - Robin Soetens et al.

15 of 29

Draft MRA system context diagram

Scope all robot related software

  • robot software
  • sideline software

16 of 29

Standardized component design

MRA Concept is inspired by

FMI/FMU

FMU is a standard for system integration

- FMU represents the simulation model

- FMI communication interface between models.

17 of 29

Standardized interface design

Each component has several interfaces

  • Input
  • Output
  • Parameters (vary per implementation)
  • State (vary per implementation)

​

All interfaces are using ProtoBuf (created by Google)

  • widely used in the world, very mature and well supported
  • multi-language support (more portable than C structs)
  • built-in compatibility for adding or omitting elements
  • easy json conversion to support testing (test-data in json)

​

​

18 of 29

How to integrate an MRA component

Inside Team repository (connect to MRA component):

  • Replace existing implementation with call to MRA library
    • Refactor to match with MRA component interfaces
    • Test in simulator and on robot

​

Inside MRA repository (for new components only):

  1. create component interface ({Input,Params,Output}.proto)
  2. Generate skeleton files
  3. implement tick.cpp
  4. bonus: implement test.cpp

19 of 29

MRA platform: a central place for MRA components

For now: https://github.com/janfeitsma/MRA-prototype

​

Contains components as well as standardization(s)

​

​

20 of 29

Introduction of MRA usage

  • MRA can be introduced in phases
    • Starting with a limited component set and migrate towards full MRA
    • Existing teams can improve by replace parts by better variants
    • Existing teams can help other teams by publishing components

​

  • MRA is middleware independent: can work with RTDB and/or ROS

​

21 of 29

MSL Reference Architecture Roadmap

Engagement is needed !!!�

  • Open up marketplace as RoboCup-MSL github project
  • Add the architecture diagrams to repository
  • Explorer if FMI/FMU standard should be used:�packaging, multiple language support, standard tooling
  • Setup releasing via artifactory
  • MRA development will be market driven:
    • Request : ask what you need the most
    • Publish: Support teams by sharing

22 of 29

MRA increases sharing between MSL teams

More sharing between teams is key for the league

  • Stop decreasing number of teams
  • Help new teams to get faster to be ready to play
  • Challenge the top teams: push to innovate

​

23 of 29

Robot TOULON (TDP 2022)

24 of 29

Falcons (2020) – Data flow

25 of 29

Falcons (2020) – ContROl Flow

26 of 29

ERSOW (2022)

27 of 29

NUBot (TPD-2021) – ROS-based

28 of 29

Why MRA: MSL status 2014 – strategy

“How are we going to keep making technical and scientific achievements, while also attracting more teams and reducing costs?

  • Increase knowledge sharing
    • Publications, MSL workshops, Robotic Open Platform (ROP)
  • Affordable robot platform for MSL
    • 5k TURTLE, Play basic soccer out of the box
  • Evaluation and annual update of MSL roadmap”

​

Standardization is missing as an explicit part of the strategy�(Ton Peijnenburg @ MSL workshop 2022)

source: RoboCup MSL - History, Accomplishments, Current Status and Challenges Ahead Robin Soetens at atl.

29 of 29

Scientific / Engineering Challenge Criteria

• Presentation

• Novelty

• Interest for either the present or the future of the league

• Scientific/Technical complexity

• Scientific relevance for the league

• Importance of demonstrated experimental results

• Relevance of the published results� presented as a support for this challenge

​