Side selection

[PhileasL]

Purpose of this PR

A way better and cleaner way to provide the side across the software. Also "fixes" (not really, just found another way) #34.

What has been done ?

• Clean localisation node,
• Fix canTransform exception in drive spamming warning log #34,
• Delete transformix package,
• Update transformix_msgs package,
• Implement a new side selection transmission across the software.

Clean localisation node

Removing VLX and it's dependencies as we're not going to use them with the new incoming lighthouse package.

Update transformix_msgs package

The only service remaining in transformix_msgs is InitialStaticTFsrv containing:

• Request:
  • Bool: final_set
  • TransformStamped: map_odom_static_tf
• Response:
  • Bool: acquittal

New side selection software architecture

Alright now let's talk about this new way of transmitting the side across the software.

First of all, keep in mind that despite the fact each component of the system (assurancetourix, asterix, obelix) needs the side, they're 3 independent systems, so they can be started in whatever order. Same thing into asterix and obelix with the transmission of the static transformation between localisation and drive according to the side, localisation node can either start before or after drive node.

Here's the trick:

• Drive node:

  • At startup:
    • Loads a default transformation that is neither blue or yellow,
    • Creates a service <namespace>/intial_tf_to_drive (transformix_msgs/InitialStaticTFsrv type),
  • -> Callback on this service just updating its static transformation _map_to_odom_tf and sending back acquittal=true

• Localisation node:

  • At startup:
    • Create a service <namespace>/initial_side_selection (transformix_msgs/InitialStaticTFsrv type),
    • Create a client <namespace>/intial_tf_to_drive(transformix_msgs/InitialStaticTFsrv type),
    • By default, the side is blue, so localisation tries to send the blue side initial static transformation to drive using <namespace>/intial_tf_to_drive:
      • Create a timer that will tries every 2 seconds to send the transformation to drive (which isn't necessarily started),
        • If after two seconds, the service didn't get any answer, cancel the client request and retries
        • else If after two seconds the service answer but not acquittal=true, retries
        • else the message has reached his destination, deletion of the timer.
  • -> Callback on <namespace>/initial_side_selection service (transformix_msgs/InitialStaticTFsrv type) -> msg from assurancetourix containing the final side of the match:
    • map_odom_static_tf in the message is useless, if final_set = true, the side is blue, else the side is yellow (final_set = false ) ( Yes, I was too lazy to implement another type of service),
    • If a transmission is trying to happen on <namespace>/intial_tf_to_drive, delete this one and the timer,
    • Update the initial static transformation to send to drive considering the final side,
    • Start a timer that follow the precedent layout,
    • Send back acquittal=true to assurancetourix.

• Assurancetourix node:

  • At startup, find the side by computer vision,
  • set up a transformix_msgs/InitialStaticTFsrv request containing the side (in final_set)
  • Create two clients:
    • asterix/initial_side_selection (transformix_msgs/InitialStaticTFsrv type),
    • obelix/initial_side_selection (transformix_msgs/InitialStaticTFsrv type),
    • Create 2 timers with the exact same behavior than the one described in localisation node above.

Reminder on the timer:

A timer is asynchronous, to popularize, it acts like a timer interrupt on µC. If it's started, it doesn't block the rest of the program. It will just execute its callback each given time gap.

[PhileasL]

@mAxYoLo01 will strategix and cetautomatix need the side selection too ? If you want, I can do the exact same thing that assurancetourix is doing for localisation but for:

• asterix/cetautomatix,
• asterix/strategix,
• obelix/cetautomatix,
• obelix/strategix,

We just have to discuss about services names.

[PhileasL]

Generalized service communication through assurancetourix incoming.

[mAxYoLo01]

@mAxYoLo01 will strategix and cetautomatix need the side selection too ? If you want, I can do the exact same thing that assurancetourix is doing for localisation but for:

• asterix/cetautomatix,
• asterix/strategix,
• obelix/cetautomatix,
• obelix/strategix,

We just have to discuss about services names.

Actually yes, both nodes need to know the side selected!

[PhileasL]

Alright @mAxYoLo01 here's the services you'll have to create in cetautomatix from asterix and obelix and strategix:

• /asterix/cetautomatix_side_selection
• /obelix/cetautomatix_side_selection
• /strategix/strategix_side_selection

Here's the python piece of code in order to create and answer this service: (extracted and adapted from here)

from transformix_msgs.srv import InitialStaticTFsrv

"""in constructor"""
self.side = "blue"
self.side_selection_service = self.create_service(
            InitialStaticTFsrv,
            "<node>_side_selection",
            self.initialSideSelectionCallback,
        ) #node in[cetautomatix, strategix]

"""in class"""
def initialSideSelectionCallback(self, request, response):
        """Assurancetourix send the side of the team"""
        if request.final_set.data:
            self.side = "blue"
        else:
            self.side = "yellow"
        response.acquittal.data = True
        return response

The fact that the node is already in a namespace prevents us to impose /asterix/ or /obelix/just before the name of the service.

As in the past, the default side is blue !

You can implement it in your future branches or merge master in your current branch and implement it directly.

From now, as soon as side transfer can be done, it'll be done !

[mAxYoLo01]

LGTM, merging!
And thanks for all the additional information 🍻