Sorry, that is likely because of how I drew the arduino side of the chart. As you have found, that function in the comm manager basically parses in a command from the serial line (or attempts to) on each update loop. Once it has a complete message, it switches that commandAvailable flag to true. The comm manager is available to all other modules in the code, so after the comm manager finishes it’s update loop, the update loops for all of the CModule-derived classes get called and if they are listening for messages, they will check to see if a message was available and, if so, whether or not the command name matches one they are interested in. The comm manager never sends the thruster messages, but rather it serves as a shared mailbox that all of the modules can check during one update loop cycle. It’s a bit inefficient as each module is doing a string comparison to see if the message is for them, and also the comm manager is spending a lot of time trying to parse strings as well, but that is what I hope to address with using a binary serialization like mavlink. With mavlink, parsing will become more of a “check the message type ID and destructure into a c struct” process, so everything should become integer comparisons as opposed to full string comparisons. This also should buy back cpu cycles on the BBB.
Also, the reasons for why we use the shared mailbox approach are that the mcu is generally running fast enough to only have one complete command buffered at any time, so we can just process it and be done with it, and there is limited SRAM available on these mcus, so we have to be careful how much memory we allocate to making copies of messages. In our case, there is no need to send copies of messages to each module that is interested when we can just signal them to look at the one we parsed exactly where it resides in memory.