Stuff Messages to increase throughput #107
Conversation
| pub fn send_message(&mut self, m: Message) -> Result<(), HydraError> { | ||
| let payload: Vec<u8, 255> = postcard::to_vec(&m)?; | ||
|
|
||
| pub fn send_message(&mut self, payload: Vec<u8, 255>) -> Result<(), HydraError> { |
There was a problem hiding this comment.
Could also create another another send function that takes just a Message type and matches it to the needed size defined by the consts in the messages library. We should have a way to send messages that isn't stuffing.
| ] | ||
| } | ||
|
|
||
| pub fn clone_states(&self) -> [Option<StateData>; 1] { |
There was a problem hiding this comment.
We should still be sending state messages, and I think we do since we don't treat it differently than any other message received (with the exception of commands).
| pub gps_pos_2: Option<Message>, | ||
| pub gps_pos_acc: Option<Message>, | ||
| pub state: Option<StateData>, | ||
| pub message_queue: HistoryBuffer<Message, 32>, |
There was a problem hiding this comment.
Why 32? Is this enough?
There was a problem hiding this comment.
I suppose the only way to find out is to see how fast they're being filled and emptied.
We could run the program on actual hardware and save metrics about its buffer size (Max Size, Min Size, 10 percentile, 90 percentile, etc)
but when I mean save metrics I meant that we can also send the current message_queue size to the ground station as telemetry data analyze it :p
I would try the 4x of the minimum amount of messages in the message queue to not be filled instantly
(maybe 16*4 = 64)
| pub gps_pos_2: Option<Message>, | ||
| pub gps_pos_acc: Option<Message>, | ||
| pub state: Option<StateData>, | ||
| pub message_queue: HistoryBuffer<Message, 32>, |
There was a problem hiding this comment.
I suppose the only way to find out is to see how fast they're being filled and emptied.
We could run the program on actual hardware and save metrics about its buffer size (Max Size, Min Size, 10 percentile, 90 percentile, etc)
but when I mean save metrics I meant that we can also send the current message_queue size to the ground station as telemetry data analyze it :p
I would try the 4x of the minimum amount of messages in the message queue to not be filled instantly
(maybe 16*4 = 64)
| messages::sensor::SensorData::EkfNav2(_) => { | ||
| self.ekf_nav_2 = Some(data); | ||
| messages::Data::Health(_) => { | ||
| if bytes.len() + MAX_HEALTH_SIZE <= MAX_SIZE { |
There was a problem hiding this comment.
Not about the PR in question but
I noticed that these MAX_????_SIZE are hardcoded.
Is there any macro that can infer that so its done automatically?
maybe a size_of plus offset_of?
There was a problem hiding this comment.
I really like this idea, my only worry is can we sync this to the mavlink defintions? @MarwanMashaly1
Right now we are not being efficient with our use of the radio buffers and will benefit from "stuffing" messages into a single transmitted radio packet.