Issues related to the introduction of new message formats

[NONONOexe]

Hello.
I'm Keisuke Ando, a member of the Rescue-AIT team developing agents.

Our team plans to present an idea to reduce communication volume in this year's TDP. However, during discussions among team members, a question arose about whether it was appropriate to implement this idea into the competition programs.

We've finally decided to incorporate this idea into the TDP and submission programs but not the competition programs. Our discussions and concerns leading up to this decision should be shared across the entire RoboCupRescue Simulation community. However, we are still determining whether to share it on the mailing list, so I'd like to share it here for now.

We're experimenting with registering new message formats to reduce communication overhead. So, within the modules of our developed agent, there's a program that decides what to do based on communication using those messages.

On the other hand, ADF encourages modularity. Just like Technical Challenges emphasized this aspect in the 2019 competition, to make the development of RoboCupRescue Simulation more dynamic, it's essential to be mindful of modularity when developing modules.

However, we cannot maintain modularity in modules that introduce a new message format. The lack of modularity arises because communication occurs between those modules using the newly created message format but fails to establish communication with others. This limitation also applies to our modules, as they operate efficiently based on the new message format we propose. However, when replaced with modules developed by other teams, their functionalities do not work.

In our team, there are both negative and positive opinions regarding introducing a new message formats.

• Negative opinions

  • It's not gentlemanly to exchange messages that are only effective within one's team, mainly when the ADF, which emphasizes modularity, is provided as a standard tool.
  • Perhaps the reason Tactics cannot be changed under the current competition rules is to encourage awareness of modularity. Thus, the rules may not account for creating a new message format under this framework.

• Positive opinions

  • ADF allows registering up to 16 custom messages through the MessageManager class. Therefore, new messages are taken into account.
  • When developing while considering the operation of other modules, that operation can be perceived as implicit messages. Therefore, developing with awareness of other modules and using custom messages may not be different.

Based on these opinions, considering fairness, we've decided to refrain from introducing a new message format this time. Making the following modifications to the ADF is more beneficial.

• Reducing the volume of standard messages
• Developing methods to enhance the expressiveness of messages.
• Introducing a way to incorporate new message formats while maintaing modularity.

We are considering what we can do on our end and are thinking about making such proposals through infrastructure competitions next year and GitHub pull requests.

---

To developers of RoboCup Rescue Simulation in Japan:

こんにちは．
Rescue-AIT開発メンバの安藤です．

私たちのチームでは，今年の大会のTDPで通信量を削減するアイデアの発表を予定しています．しかし，チームメンバーと議論していくなかで，このアイデアを競技会用のプログラムに導入してもよいものかという疑問が浮上しました．

最終的な判断として，私たちは今回のアイデアをTDPと提出用プログラムに導入しますが，競技会のプログラムでは参照しないこととしました．私たちはこの決断に至るまでの私たちの議論や問題意識をRoboCupRescue Simulation全体で共有すべきだろうと考えています．とはいえ，メーリングリストで共有すべきかを迷ったため，一旦ここで共有したいと思います．

私たちは通信量を削減するためのアイデアのなかで，新しい形式のメッセージの登録しています．そのため，私たちの開発したエージェントがもつモジュールの間では，そのメッセージを利用したやりとり，それにもとづき行動を決定するプログラムがあります．

一方でADFでは，モジュール性を意識しています．2019年の大会ではこれを意識したテクニカル・チャレンジもあったように，RoboCupRescue Simulationの開発をより盛んなものにしていくために，私たちはモジュールを開発するとき，このモジュール性を意識すべきだと考えています．

しかし，新しいメッセージの形式を導入したモジュールでは，モジュール性を完全に保証することができません．なぜなら，これらのモジュールの間では新規に作成されたメッセージの形式を用いて通信しますが，それ以外のモジュールとの間ではこの通信が成立しないためです．これは私たちのモジュールも同様で，私たちが提案する新しいメッセージをもとに効率的に動作します．しかし，ほかのチームの開発したモジュールと入れ替えたときには，それらの機能は働きません．

このことについて，私たちのチームでは，新しいメッセージを導入することへ否定的な意見と肯定的な意見があります．

• 否定的な意見

  • 自分のチームでのみ有効なメッセージをやりとりするというのは，モジュール性を意識するADFが標準のツールとして提供されているうえで，紳士的でない
  • 現在のルールでTacticsが変更できないのは，モジュール性を意識してもらうためにあるのではないか．したがって，メッセージを新たに作成することは考慮していないのではないか

• 肯定的な意見

  • ADFではMessageManagerというクラスを通じて16種類までのカスタムメッセージが登録できる．そのため，新しいメッセージは考慮されているのではないか
  • ほかのモジュールの動作を考慮して開発すると，その動作は暗黙的なメッセージと捉えられる．そのため，そもそもほかのモジュールを意識した開発とカスタムメッセージを利用することは本質的には同じではないか

これらの意見から，私たちは最終的な決断として，公平性を考慮し，新しいメッセージを導入するのを今回はやめることとしました．本質的には，ADFに以下のような改修を加えるのがよいと考えています．

• メッセージの通信量を削減する
• メッセージの自由度を高められる方法を導入する
• モジュール性を保持しながら，新しいメッセージを簡単に入れられる方法を加える

私たちの方でも，来年以降のインフラのコンペティションやGitHubのプルリクエストを通じて，このような提案をしていければと考えています．

[gnardin]

Dear Keisuke Ando,
I do not know exactly what is changed in the ADF to register these new messages, but I think your team made a good decision in not incorporating the new messages in the team's code. Mainly because the chairs running the competition replaces only allowed classes in the default ADF. Even if you incorporate changes to the ADF, your implementation could have been disregarding when running your team code in the competition.

Obviously I would need more implementation details for commenting more on the situation. But your suggestion of proposing the implementation in next year's Infrastructure Competition seems a nice approach. The only problem is that you would need waiting longer than 1 year to release the proposal. You could release your code publicly soon after this year's competition and apply the approach for the next year's Infrastructure competition. You may even get some improvement suggestions until next year's competition.

Kind regards,