-
Caileigh Fitzgerald authored
------------- - new node `tdma_slotted_aloha`. New message type: `TdmaSlottedAlohaStatus` - this node creates a new slot type `~aloha_slots`. These slots are intended to be shared slots with other platforms. - by default `~aloha_slot_priority` is `0` meaning, all traffic is allowed. __This is not ideal for a real/simulated system__ - the idea is there are message queues that move more episodic bursty traffic (e.g., chat) so slotted aloha but priority based tdma slots under the hood: - message_queues with priorities GREATER than `~aloha_slot_priority` can be transmitted: - during `aloha_slots` OR during any other `comms_slot` or remaing time in a `nav_slot` (typically these slots are just == active_slots) - message_queues with priorities LESS than `~aloha_slot_priority` cannot be transmitted: - during an `aloha_slots` but can be transmitted during any other `comms_slot` or remaing time in a `nav_slot` (typically these slots are just == active_slots) - now actually passing `minimum_priority` to populate service request in the case of `aloha_slots` - added helper method to tdma super class for parsing slots string (can be string,list,int but needs to end up as a list of ints, thats now one method to avoid repeating that parsing out multiple times). - added plumbing for gating minimum priority of queue - `~aloha_slots` do not have to intersect with active slots. Not sure if there is a ideal way to use it as many configurations could create the same slotted aloha tdma system. For now, there are warnings and info at points where those values are set. I've been configuring the aloha slot as a slot that is not in the active slots list. Weither or not an `aloha_slot` overlaps with a `comms_slot`, an `aloha_slot` will pass a `minimum_priority` to `tdma.send_next_packet(minimum_priority=aloha_slot_priority)` - `~aloha_slots` set after `~nav_slots`. Since `~nav_slots` are supposed to be for pings or ping_transponders callbacks, the assumption is the user did not mean to have a `nav_slot` in the `aloha_slot` because `aloha_slots` are shared slots. Not for users to send nav pings. It keeps the `aloha_slots` and removes the `nav_slots` that overlap from `nav_slots`. - since `tdma_slotted_aloha` inherits from `tdma_advanced_node` it also uses the same dynamic reconfigure callback Breaking Changes: ----------------- - `GetNextPacketData.srv` field `min_priority` was changed to `minimum_priority` to match other instances in the code. TODO: ----- - dynamic queue priority handling - possibly handle a list of aloha_slot_priorities so you can have multiple aloha slots with different gates (making it easier to segment)Caileigh Fitzgerald authored------------- - new node `tdma_slotted_aloha`. New message type: `TdmaSlottedAlohaStatus` - this node creates a new slot type `~aloha_slots`. These slots are intended to be shared slots with other platforms. - by default `~aloha_slot_priority` is `0` meaning, all traffic is allowed. __This is not ideal for a real/simulated system__ - the idea is there are message queues that move more episodic bursty traffic (e.g., chat) so slotted aloha but priority based tdma slots under the hood: - message_queues with priorities GREATER than `~aloha_slot_priority` can be transmitted: - during `aloha_slots` OR during any other `comms_slot` or remaing time in a `nav_slot` (typically these slots are just == active_slots) - message_queues with priorities LESS than `~aloha_slot_priority` cannot be transmitted: - during an `aloha_slots` but can be transmitted during any other `comms_slot` or remaing time in a `nav_slot` (typically these slots are just == active_slots) - now actually passing `minimum_priority` to populate service request in the case of `aloha_slots` - added helper method to tdma super class for parsing slots string (can be string,list,int but needs to end up as a list of ints, thats now one method to avoid repeating that parsing out multiple times). - added plumbing for gating minimum priority of queue - `~aloha_slots` do not have to intersect with active slots. Not sure if there is a ideal way to use it as many configurations could create the same slotted aloha tdma system. For now, there are warnings and info at points where those values are set. I've been configuring the aloha slot as a slot that is not in the active slots list. Weither or not an `aloha_slot` overlaps with a `comms_slot`, an `aloha_slot` will pass a `minimum_priority` to `tdma.send_next_packet(minimum_priority=aloha_slot_priority)` - `~aloha_slots` set after `~nav_slots`. Since `~nav_slots` are supposed to be for pings or ping_transponders callbacks, the assumption is the user did not mean to have a `nav_slot` in the `aloha_slot` because `aloha_slots` are shared slots. Not for users to send nav pings. It keeps the `aloha_slots` and removes the `nav_slots` that overlap from `nav_slots`. - since `tdma_slotted_aloha` inherits from `tdma_advanced_node` it also uses the same dynamic reconfigure callback Breaking Changes: ----------------- - `GetNextPacketData.srv` field `min_priority` was changed to `minimum_priority` to match other instances in the code. TODO: ----- - dynamic queue priority handling - possibly handle a list of aloha_slot_priorities so you can have multiple aloha slots with different gates (making it easier to segment)
Loading