Preview images occasionally jump slightly during simulated camera and telescope motion

[Short-bus]

While program is simulating movement and photographs the preview images sometimes show a jump in the motion of the image. Both the simulated photograph and the preview markings shift consistently briefly. If this was live I would have assumed this was some mechanical glitch in the motion, but it's happening when running entirely in simulation mode. Generating a 'fakephoto' and then marking up that fake photo. I would assume these to show very smooth motion. It's a jump for a single preview image, the next preview image returns to the original track. Not a critical issue, it is only a small alignment shift, but unsure what the cause is. Does it suggest some more subtle random issue with position or motion calculations?

[Short-bus]

To try to recreate the specific instance, I'm adding the option to 'offset' the clocks that the software uses. So the original date/time of the jumps can be recreated on demand. Startup parameter 'clock=YYYY.MM.DDThh:mm:ss.ssss' (ISO8601 format datetime) Risk that this feature takes a bit of debugging too! But useful longterm for recreating specific issues more easily.

[Short-bus]

Frame by frame analysis shows that the jumping is aligned with the direction of travel, wondering if there's an issue with the timestamps being passed to FakePhoto/CreateTargetImage and MarkupPreview functions. Tracing how up-to-date the latest camera position information is as this is the basis of most of the image alignments.

[Short-bus]

Simulated extremely long observation runs to see how the system behaves over 12hours plus. It looks like there may be two issues causing similar symptoms. 1) When generating images, the position of objects is based upon the reported camera angles. These should update every 10 seconds, however sometimes the update does not arrive in time, the angles are then quite old. This causes small mismatches in the image, just fractions of a degree. I think this is relatively simple to resolve by estimating the position of the camera in a more realtime way. 2) The larger jumps of several degrees are more mysterious, but much less common. This may be a fault with the trajectory plan or something within the microcontroller code. More investigation needed.

[Short-bus]

The centre of the preview was based upon the last reported position of the motors. There were occasions where the RPi was busy doing something else for quite a while. During those periods the status messages from the motorcontroller were processed late. That meant that the 'centre' of the image was out of date and all the preview markups were off. Currently testing a new version where the centre of the image is always considered to be the current target position from the skyfield calculations instead of the last reported motor position. This seems to have eliminated the problem in simulations. Waiting to see if autumn live observations work the same way.

[Short-bus]

New solution has improved the situation, though in testing there was a single instance where it still chose a poor centre for the preview image. Not sure if the telescope was 'tuning' at the same time though.

[Short-bus]

Improvements merged into Summer2023 development round.