Improve the game strategy development workflow

[SyrianSpock]

We've seen a lot of improvement since we introduced the following:

• unit tests to cover the feasibility of some GOAP goals
• a simulator to simulate a whole game, assuming no failures

We need to continue improving on our tools to make it easier to iterate over the game strategy, especially in the last few days rush. For that we need to:

• [ ] improve our simulator setup (code refactoring, use liberror for logging and reintroduce more thorough unit testing)
• [ ] improve feedback from the simulator (display the robot position in 2D)
• [ ] extend the simulator for error handling (introduce configurable opponents, probabilistic failure)
• [ ] consider extending the simulator to more complex

[antoinealb]

I think it is more important to increase our strategy productivity in the early days of the strat dev rather than the last ones. In my mind the robot should have an almost working strategy (although tuning will always be required) on the day the wiring is finished. I would love to have a simulator which is complete enough to have motions on them (Gazebo).

One random idea that I had was to use the master firmware running on a real master board, but where the motor manager (and other CAN comms) could be replaced with Protobuf messages sent over UDP. Note that if we rewrite motor manager to use messagebus, we might even get there "for free" (without modifying the firmware).

I thought a lot about the different options, and I feel that this one is the best for the following reasons:

• Very little modifications to the runtime code. I think the same board could even be used without reflashing anything other than config if done in a smart way.
• Very accurate behaviour.
• Gazebo already exposes an API for this type of stuff, although its not Protobuf-based I believe.
• Reasonably scalable: We have a ton of those Nucleo boards, and we can easily buy more if needed.

Note that some parameters, such as the pid configuration and so on would probably need to be re-tuned for the simulation.

I would be interested in working on the parts that are running on the master firmware. I can write some of the bridge linking Gazebo and our stack. I would definitely need help with the Gazebo setup (simulation world, robot, etc.).

[antoinealb]

https://wiki.ugfx.io/index.php/Remote_displays Could also be useful for some simulation ^^

[lyris85]

I'm down to help deploy the middleware with Gazeboo

[SyrianSpock]

From a purely technical point of view, this is a good idea From a problem solving point of view, I don't see this solving many of our problems for a huge development cost. I think we gain a lot more with less simulation (just enough to prepare the game strategy, not to simulate the physics of the robot itself). I believe the critical point is stress testing the game strategy with error injections so that we can test our error handling logic, since this generates different behaviors.

[antoinealb]

Dont you think that this is more of a job for automated testing ?

[SyrianSpock]

Yes, it all needs to be automated.

[antoinealb]

Closing this, as we are now working on a complete simulation instead of just the strategy (under /hitl).