Rotating Focuser - changing one to match another on multiple-scope array

[macnmotion]

Hi, I'm having an issue with something that seemed pretty simple to me.

On our 4 scope array (4 matching 300mm telescopes), we have the following cameras:

Array 1 - FLI 29052
Array 2 - FLI 16803
Array 3 - FLI 16803
Array 4 - FLI 29052

All have Optec Gemini rotating focusers. In order to minimize loss of edges due to rotation mismatch, I thought we could measure the rotation required in PixInsight's StarAlignment process based on aligning an image from each of Arrays 2, 3 and 4 to an image from Array 1, and then rotate the focuser on each of Array 2, 3 and 4 the same value to counter the misalignment of the cameras. After doing this, I find that Array 4 is rotationally matched to Array 1. However when I counter the rotational values for Arrays 2 and 3, and take another series of test shots, Arrays 2 and 3 are not aligned with Array 1. In fact I see no correlation between the before and after rotation values reported by the StarAlignment process (i.e. I'm not missing a + or - sign in my offset value).

Is this because the sensor sizes and dimensions are different between the 29052 and 16803? Am I misinterpreting the rotation value reported by PixInsight when star aligning? Obviously something is wrong with my logic, I'm uncertain as to what it is.

If anyone has an idea of how to determine the correct rotational offset between Array 2 (or 3) and Array 1, I would appreciate it. Thanks.

Andy

Not sure if this info is necessary, but:

FLI PL16803 - 4096x4096 px - 36.9x36.9mm sensor - 9µ pixel size

FLI PL29052 - 6576x4384 px - 36.1x24.1mm sensor - 5.5µ pixel size

[chris.bailey]

Andy

I may be wrong but I think the rotations reported by star alignment is around the image origin (hence images rotated by 180 degrees after a flip having offsets the size of the image) whereas what you want reporting is the rotation about the image centre. You can get the information I think you need by using Image solver, which will give the rotation wrt North of each image and thus allow you to rotate one to match the other.

Chris

[macnmotion]

Hi Chris, I wondered if it was something like that, especially when some of the dX and dY numbesr from StarAlignment were more than a few pixels. I will take a look at the ImageSolver. Thanks for the idea.

Andy

[bulrichl]

Presupposed that the image is not strongly distorted, the center of rotation doesn't matter. The offset is a translation which is independent of rotation.

@Andy:
are the images of all four instruments true sided?

Bernd

[macnmotion]

Hi Bernd,

I'm not sure what you mean by true sided. The scopes are Officina Stellare RH300 at f/3.0. We are not using a reducer. Using scope 1 with an FLI 29052 as the registration master, scope 4 (also with a 29052) aligns properly after applying the rotation offset from the PixInsight Star Registration process. Scopes 2 and 3, both with 16803s, do not align when using rotation offsets from that same process. The only difference is the camera (all focusers are Optec Gemini).

I don't expect that edge distortion is the issue here. Any other thoughts would be appreciated. Thanks. Andy

[pfile]

out of curiosity what software are you using to drive the cameras/mount/rotator? can't you just set a sky angle in that software? or did you have to roll your own software due to having multiple cameras?

rob

[macnmotion]

Hi Rob,

One of the functions we had our custom developer add was rotation offsets. We use a custom version of Voyager for overall system control. Note that we've had Voyager looked at to see if the error was there, apparently it isn't.

Yes, we can use Optec Gemini's software control to rotate each of the focusers independently. When we used the same values from PI, we got the exact same results as when using the rotation offset functionality in Voyager (verifying that the issue wasn't within Voyager). The rotators have all been homed. Somehow the numbers I'm getting from PI aren't the right numbers, at least for the scopes with the different cameras.

Andy

[bulrichl]

Hi Andy,

I guess it is the same as in german: true-sided = contrary of mirror-inverted. It is a very unlikely possibility, but currently I cannot imagine another cause. And it's easy to check.

Bernd

[pfile]

Hi Rob,

One of the functions we had our custom developer add was rotation offsets. We use a custom version of Voyager for overall system control. Note that we've had Voyager looked at to see if the error was there, apparently it isn't.

Yes, we can use Optec Gemini's software control to rotate each of the focusers independently. When we used the same values from PI, we got the exact same results as when using the rotation offset functionality in Voyager (verifying that the issue wasn't within Voyager). The rotators have all been homed. Somehow the numbers I'm getting from PI aren't the right numbers, at least for the scopes with the different cameras.

Andy

doesn't Leo let you solve and sync to refine the rotation/pointing? i guess what i am asking is if you just tell voyager that you want your PA to be sky angle 32 degrees (for instance) why won't it rotate all the cameras to that angle?

or are you trying to undo 3d-2d projection effects by rotating the cameras ever so slightly to one another?

rob

[macnmotion]

Yes this is to eliminate minor discrepancies between mechanical rotation of the 4 scopes. We can adjust with mechanical measuement tools and get close but not perfect. Leo has built in an offset table based on array scopey 1 being "0." If we rotate array 1 for framing, the others will rotate to match, based on their offsets. Leo isn't solving to determine rotational differences, although I'm sure he would add that if we asked. But when we scoped out the functionality it seemed unimportant, as we only needed to determine offsets once (or until the next time any element was physically changed).

As you can imagine, with 4 scopes the rotation differences could be additive if there are scopes rotated clockwise and counterclockwise to the scope used for alignment reference. Before you know it, you can lose quite a bit of your FOV due to these differences.

[pfile]

ok i see - solve & sync on all 4 cameras seems wasteful if you know the offsets. but i guess what i was saying is that you don't need to worry about any offsets if you just loop over all the cameras and solve/sync to set the rotation angle. in other words, most programs already do this for a single camera so "all" he needs to do is iterate over all cameras being controlled and problem solved. but again now you're talking about 4x the time which could be significant.

at any rate, back to the original question, i'm not sure why SA or ImageSolver would not give the right info. in the end ImageSolver should tell you how many degrees rotated the image is compared to north, so computing the offsets should be straightforward. not sure why it does not work. if you solve the post-offset fix images, how do the angles compare to the pre-fix images?

rob

[macnmotion]

Rob, when you say that the SA process would tell how many degrees rotated the image is compared to North, is that right? I thought it tells how many degrees rotated compared to the registration image.

[pfile]

ImageSolver gives you vs. north... SA is with respect to the reference.

rob