fixed/improved angular orbit

[JAndringa]

angular orbit was not working properly, so I just rewrote it. Needs some finetuning but works well enough for now.

Comments for the reviewer

Pre pull request checklist:

Code Quality

• Is the code is understandable and easy to read
• Changes to the code comply with set clang-format rules
• No use of manual memory control (e.g new/malloc/colloc etc)
• Are (only) smart pointers used?

Testing

• All tests are passing.
• I added new / changed existing tests to reflect code changes (state why not otherwise!)
• I tested my changes manually (Describe how, to what extent etc.)

Commit Messages

• Commit message is saying what has been changed, why it was changed? Remember other developers might not know
  what the problem you are fixing was. Note also negative decision (e.g., why did you not do particular thing)
  TLDR: Commit message are comprehensive
• Commit messages follows the rules of https://chris.beams.io/posts/git-commit/

[umer99roboteam]

The orbit of the robot is much more smooth
As a result the passing has vastly improved and gameplay is faster
The orbiting seems quite fast. The actual robot might loose the loose the ball. However, seems that can be tuned

[rolfvdhulst]

Has this been tested with real robots?

[rolfvdhulst]

See comments. Nothing major.

[rolfvdhulst]

Remove before merging.

[rolfvdhulst]

Seemse unrelated to what the pull request is about.

[alexander-de-ranitz]

As Rolf asked, was this actually tested on the field? Based on "The actual robot might loose the loose the ball", I'm guessing not :)

Based on the changes you made, I can believe this works better in GrSim, but I highly doubt it does what you expect on the field. A lot of the code you changed/removed in this PR was specifically designed and tuned to improve performance on the field (probably at the expense of performance in GrSim, but we didn't really look at this much as we created this quite shortly before the robocup). Things such as padding the angle to account for delay and delegating the decision of when to shoot to the robot instead of the AI can be really useful with actual robots but are quite useless/counterproductive in the simulator. Of course, it is still important everything works well in the simulator, but doing so at the expense of the performance on the field isn't a good approach IMO. Of course, if needed, you could add some if (playingOnTheField) and if (playingInSim) to deal with cases where we want to do things differently due to fundamental differences between actual robots and the simulation, just be sure not to let the sim and real-life performance get too different.