Throttle Lighting Commands

[dennisss]

I presume that currently lighting commands are sent at the same 100Hz frequency that is used by the motion. This may cause the network throughput to look like we're flying double the drones.

• A LightingController should remember the last values it sent to the Vehicle
  • Don't over send values that haven't changed
  • But, double send the commands in case the first packet was lost
• Limit update rate to visible rate
  • 50Hz can be achieved by only updating ever 2 steps

Discuss an appropriate milestone for this depending on people's availability.

[tessmichi]

So far I have been able to limit the amount of commands - the controller keeps track of each light's current intensity and only sends a new command if the intensity has changed by >0.01 Waiting to close this, as I'm not sure what else should be done

[abramowitzK]

You can have a counter in the player class that only updates lighting if it's even. Increment it everytime you call step

[tessmichi]

Will do this right now

[tessmichi]

I would actually like to evaluate this a little bit more before choosing to implement it. When I implemented the suggestion to only update on even hundredths of a second, it looks like the lights aren't getting updated frequently enough. With the already implemented solution so far - the first bullet point from Dennis's original comment - such that the intensity is only updated when it has changed by >0.01, the lights already only get updated 1,2,or3 times per tenth of a second depending how fast a jocs file says to update the lights. And if those two updates happen to fall on an odd hundredth of a second, that tenth of a second could be skipped all together. I assume this won't be acceptable but will ask Mike about it.

[tessmichi]

Another concern for throttling based on time is that for strobe actions, we might need 100th of a second accuracy. A workaround would be to separate the code for regular light actions versus strobe actions even more, but we should discuss on Saturday.