Running pi-lomar in Southern Hemisphere

[Short-bus]

Currently pi-lomar will error out if you give a home latitude in the Southern Hemisphere.

This a protective error message because the telescope has not been tested south of the equator yet.
I don't anticipate any problems with the 3D printed structure or with the motorcontroller, however I don't know yet how the main software on the RPi should behave in the South.

I suspect that there could be some 'inversions' of some movements or measurements needed, but have not got a good test environment to prove it for certain.

The software can be operated with just the RPi and the microcontroller talking to each other, so it should be possible to test and finetune the algorithms for the Southern Hemisphere without any physical movement taking place, which should be safer.

The first unknown is how the 'skyfield' libraries return the altitude/azimuth for star locations. The documentation says that the azimuth is always '0'degrees = North. '0'degrees is currently the limit of movement for the telescope, so as an object passes due North (its highest in the sky) the telescope will have to slew 360Degrees to continue the observation. Does it make sense to invert the angles somehow, or even to change the movement limits and home positions set for the telescope?

[Short-bus]

After some experiments the main issue looks like it's an 'irritation' in the behaviour and not fatal.
Skyfield reports positions using the same references in the Southern Hemisphere.
The telescope will therefore operate in the south as long as the azimuth home position remains 180Degrees (due South).

The issue that remains is the 'unwinding' behaviour as targets pass through due North.

The motorcontrol logic does not understand that the Azimuth can get from 359Degrees to 1Degree by moving 2Degrees clockwise.
It will move 358Degrees anticlockwise instead.

This behaviour was originally a 'feature'.

1. It means that the telescope will not continually twist the power cables. Instead it unwinds each time it tries to track through due North.
2. Due North was the less common position to be observing things in my locality when the software was written, so the interruption is rarely an issue.

However in some latitudes it may be more common to track objects through due North.

In the current operation the telescope will work, but as a target passes due North the telescope will perform the 'unwinding' manoeuvre mid observation - in effect this just pauses the photographs for a few minutes while the telescope resets its azimuth. It's not fatal, just a pause.

The unwinding behaviour occurs because of the microcontroller's circuitpython code. (code.py).
The steppermotor() class has two methods MoveMotor() and MoveFullStep() which control the movement.
If my understanding is correct then the logic should be modified across these two methods to make the telescope understand the shortcut that it can take.

If it can take the shortcut route, then observations which track across due North will run more smoothly.
However, if the 360Degree unwinding behaviour is removed entirely there is a risk that many continuous turns of the telescope in the same direction would eventually twist the power cables - that suggests that the unwinding behaviour may still make sense, but the position of it should perhaps be configurable?

More tests to be done to prove this, and to evaluate suitable solutions in the code. The current software looks like it works further south as is, even if it is not quite as efficient in some cases.

[Whiteeeey]

Thanks for the information. I will have a look at these areas of the code. I think a nice way to solve this problem would be to make the home position configurable as any compass direction and only allow the telescope to rotate 180 degrees in either direction from home. Then you could setup your observatory facing in roughly the direction of the object you are observing on the closest compass bearing and the change of direction would be as far away as possible for each observation.

[Short-bus]

New version of src/pilomar.py and circuitpython/code.py in the 2024-01 branch.

This is currently under test.

src/pilomar.py introduces a new parameter OptimiseMoves. Default FALSE - which retains previous behaviour.
False: Telescope will not pass through Due North on any move, it will 'unwind' the long way round to the target position instead.
True: circuitpython/code.py can take the shortest path between any two positions. Telescope will pass through Due North if that is the shortest path to the target position.

Further refinement to come if this latest change passes tests.

[Short-bus]

The main GitHub branch now has the latest version of the software. It should now accept southern latitudes without complaint.
There is also now the 'OptimiseMoves' parameter in the parameter file, if you set this to TRUE, the limiting position of the azimuth is nolonger enforced, the telescope is free to move as much as needed in any direction. It will issue a warning if enabled to remind you to take care of cables getting tangled.