Investigate excessive slew command lateness with sensor fusion target
Opened this issue · 3 comments
During some of the first testing with the SensorFusion target on 5 December tracking stars and planets I noted that the slew command lateness was spiking as high as 60ms without the camera capture program running which is not so great.
Investigate this and determine a path forward to correct it. The fix could include optimization or even increasing the control loop period.
On 6 December I tried running the code indoors with mount motion disabled and manipulating the camera sensor data to create a fake target, but in this environment the command lateness was very low, typically under 1 ms with only occasional spikes above that. I also timed the get_sensor_data() method in the controller class and found that the mean execution time was about 21 ms with the SensorFusion target, compared to 25 ms for CameraTarget. Clearly something about my indoor setup does not have enough fidelity to reproduce the problem.
Looks like the problem is only significant when there is competition with capture for CPU. When I ran this evening with capture running but writing to disk paused I saw similar slew command lateness as a couple nights ago. But as soon as I quit the capture program the lateness was sub-1ms most of the time. The time for process_sensor_data() dropped a bit to around 19ms mean, but that along shouldn't be the difference between meeting deadlines vs not (I think).
This is still in contrast to sensor fusion disabled though, where the lateness is minimal with and without capture running.
CameraTarget meets its deadlines consistently with capture not running, but has spikes up to not quite 10ms fairly often when capture is running.