hey Jasem,

thank you for still working on the problem.
I belive i had the same experience:

First slew to M42 i got again low errors und made about 10x 45sec frames witch were great all looking like this:


(Again 76/342 with RP HQ Cam 45 sec)

Than i slewed to another part of the sky and got again low errors (+-5) and the frame looked like this (30 sec) -> drift was back:


(30 sec)
So it cant be only the error...

>>This actually worked quite well, but I still couldn't get perfect tracking.

Sounds complicated - but i would be happy with a "magic" value to set can you push the solution into the code, so that i can test it? Or do you think it is realy not usable?

Regards,

I just pushed the code, there are new controls:
1. Dead Zone: this just sets the dead zone so that it doesn't switching rapidly switch directions.
2. Clock Multiplier: Controls the multiplier to the clock rate, defaults to 100% and should probably not change. Was just experimenting with this.
3. Offset: Magical offset for each axis. It is added to the error calculated. This would have the effect of shifting the target

I will test as soon as possible under real sky and report back!

Thank you, Jasem. Falling asleep at the keyboard is some dedication! I apologize for being worthless toward the effort this last week. I've been moving my father-in-law and working on the lawn tractor. One thing I noticed, which is a little unrelated to the new code, is line 1717 through 1721 of the .cpp file:

m_Controllers[AXIS_AZ].reset(new PID(1, 50, -50,
Axis1PIDNP[Propotional].getValue(),
Axis1PIDNP[Derivative].getValue(),
Axis1PIDNP[Integral].getValue()));
m_Controllers[AXIS_AZ]->setIntegratorLimits(-100, 100);

Should this be:

m_Controllers[AXIS1].reset(new PID(getPollingPeriod() / 1000, 50, -50,
Axis1PIDNP[Propotional].getValue(),
Axis1PIDNP[Derivative].getValue(),
Axis1PIDNP[Integral].getValue()));
m_Controllers[AXIS1]->setIntegratorLimits(-100, 100);

or does it even matter? Likewise for Axis2, if so. Looks like it would only affect the polling period if anything.

Yes, it should be as you said especially if I am going to test at different frequencies, thanks for pointing this out!

Ok yesterday I spent some time on the driver. I added a separate tab called tracking to consolidate all the tracking properties I've been adding. So the issue I found is this:

The driver was doing a good job at tracking the object, at least theoretically. That is, the errors are kept to a minimum (within 1-2 steps, so for 1.6 steps per arcsecs, that's very close). However, this doesn't correspond to reality. Let's take this as example (there is no pointing model here involved):

1. GOTO and center star at AZ: 60.0 and AL: 30.0
2. The slew is finished and tracking is engaged.
3. PID works to keep the error between current encoder and target encoders to a minimum.
4. Theoretically, the current encoders indicated we are exactly centered on the star, but in reality it has already drifted off.

I tried different tricks to get around that. Last trick I tried yesterday (before failing asleep again around 2 AM) is to introduce an offset that would track faster, but then remove this offset from current encoders. So in retrospect this would make the telescope indicator appears centered on target, but in reality the encoder speed is a bit faster to catch up with the star. Though I'm afraid this might turn on to be instrument dependent even though I am hoping that it is just position dependent. This way the offset can be adjusting before tracking is started depending on the current AZ/AL of the target.

If anyone has better ideas, please let me know.

No problem - you would have caught it at some point. A general question on that same line: why is AXIS_AZ and AXIS_ALT used inside the bracket instead of AXIS1 and AXIS2 in this instance (i.e. m_Controllers[AXIS_AZ].reset......... versus m_Controllers[AXIS1].reset).

In regard to your latest post, I see what you are saying, but I'm a little perplexed at how Mat was able to obtain ten 45 sec subs with no star trailing?

I'll download and test to see if I can spot any trends. I'll also look at the tracking methodology again to see if there's an obvious item that's missing where we could eliminate the need for unnecessary offsets.

Thanks for your work and helping point our testing efforts in the right direction.

So just for me and tonights testing:

You say first slew to target and if drift apears than use magical offset to correct and than eventually disable magic offset correction and see if it leads to a good result?

>>In regard to your latest post, I see what you are saying, but I'm a little perplexed at how Mat was able to obtain ten 45 sec subs with no star trailing?

That is the strange thing: why all the problems sometimes are not there - perhaps we are hunting a hardware issue? Or i was able to take the frames, because the drift was happened to be appropriate for a period.

(Just for protocol the M42 frames in a row as attachment with exif data.)

Because the rate is different at various locations in the sky, most likely due to how fast the motor have to move when it is closer to the meridian and farther from the poles. I submitted one *last* change to the driver and will leave it as is. The issue is not PID, it's working perfectly fine as is, but the 1.6 steps/arcsec definitely does not hold true. As far as the driver is concerned based on the encoder values, everything is at the right place.

I've introduced AZ and AL offset in steps that would force the mount to chase an offset to the target that might help a bit, but this is not a long term solution. I believe I'm done with this driver now, spent too much time on it.

First of all, thank you very much for the effort you have put into the driver lately! I think this has taken things a step further.

I will install the last fix and maybe we will find a workflow that will allow the current version to work reasonably well!

My ideal case would be a todo list of options that you work through for each target in order to achieve the best possible result. If I get any further here, I'll report back.

Thanks also to Michael!

Jasem - could it be that we are missing the time for acceleration (or deacceleration) as the mount axes are changing speed?

If so, we might be able to add a timer to obtain when the axis meets the set speed. The change in time could be used along with the two previous axis frequencies to obtain an average acceleration which could be used to determine an angular displacement (in microsteps). This displacement could be fed back into your "offset" which you are adding [ AxisOffsetNP[ALSteps].getValue() & AxisOffsetNP[AZSteps].getValue() ]. This might eliminate the need for user input of an offset.

I haven't fully thought it through and may need to draw a logic diagram to convey my thoughts.

Thank you Michael. I believe it is already accelerating and decelerating all the time due to the PID loop. We're setting a different speed per cycle. The issue is that as far as pure encoder value goes, we're at the correct place. Let's take this for example:

1. AZ=60, AL=20. Tracking starts
2. Object position is updated. Now AZ=60.1 and AL=19.9
3. PID tries to change the tracking speed to offset +.1 in AZ and -0.1 in AL
4. Current encoders indicate we are indeed at AZ=60.1 and AL=19.9 .... however, this is not true, perhaps we are at AZ=60.05 and AL=19.95. We can't tell because you can't trust the encoders alone.

Another quite complicated solution is to solve at two different positions in the sky and then calculate the actual microsteps/arcsecs range. Currently, it's hard-coded to 1.6 microsteps/arcsec, but I think this is actually variable across different positions in the sky for the AZ-GTI. Theoretically, you can build a map of different encoder <---> arcsecs conversion rates at different locations in the sky and then use that. But this is way too complicated and just get a better mount already