DIMM Auto Acquisition

Operation

Start

As of 20161109, auto-acquisition is part of the DimmServer software. To start, select Start Auto-Acquire on the GUI:

Note that the auto-acquire thread will exit if it cannot centroid after trying a configurable number of stars. So, it may need to be restarted sometimes - but the GUI will have the start button available when it has exited.

Stop

Stop with the button:

Details

Note: The standalone acquisition client was merged into the server software in Nov-2016.

A new DIMM acquisition client was created as a standalone program in Spring-2016. The only difference to the existing DIMM usage is that the mount and camera are now set up to auto-connect. So, just launching the DIMM server and GUI will connect to the mount and the camera. Obviously, the DIMM server is required by the acquisition client, but the GUI is also required. The first release (Mar-2016) was meant to check out the new functionality in a way that least perturbed the original use of the application.

See LBTO DIMM Operating and Software wiki page for starting up DIMM in the usual way.

If LBT is not on-source, it will check every 10secs and then sleep.

When LBT goes on-source, the acquisition client will:

1. slew the mount to the first star in the current DIMM list (currently sorted by distance to LBT)
2. grab the web image and centroid
3. slew the mount to move to the star
4. repeat the grab-centroid-slew until within a configured threshold
5. start measuring

The acquisition thread stops if it cannot centroid after trying a configurable number of stars. So, it may need to be restarted, via the button on the GUI.

Configuration items associated with the acquisition client
Dimm.Acquisition.pixelscale	Pixelscale [arcsecond/pixel] for the webcam, 4.5x3 deg fov with 720x480 pixels
Dimm.Acquisition.Xtarget Dimm.Acquisition.Ytarget	X,Y pixel positions of the DIMM hotspot on the web cam using 352x288 image file
Dimm.Acquisition.XcorrectionGain Dimm.Acquisition.YcorrectionGain	applied to web cam centroid correction before moving DIMM mount
Dimm.Acquisition.starsToTry	how many of the stars in the acquisition list to loop through
DimmAcquisition.acqThreshold	arcmin threshold of when to stop acquisition and go to measuring
Dimm.Acquisition.maxAcqPasses	how many times to try the centroid-move loop to get to acqThreshold
Dimm.Acquisition.flatImage	filename in etc for the subtraction image to be applied for centroiding
Dimm.Acquisition.subtractImage	whether to subtract the flatImage file before centroiding

The original version dumped the following every two minutes:

=====================
LBT is NOT tracking;  DIMM is NOT measuring 
Server LST:22:28:18.90  RA:17:50:01.83  DEC:89:15:50.79  AZ:120:35:59.84  EL:89:59:50.36
First 5 catalog stars, of 7
  star 0 59.5691  2.93 RA 22:43:00.13 DEC +30:13:16  AZ 127:24:09.16 EL 86:00:19.91
  star 1 61.7724  2.44 RA 23:03:46.33 DEC +28:04:56  AZ 118:49:47.84 EL 81:04:20.16
  star 2 65.2098  3.48 RA 22:50:00.10 DEC +24:36:06  AZ 148:13:34.33 EL 80:36:37.31
  star 3 74.6515  2.49 RA 23:04:45.62 DEC +15:12:19  AZ 152:32:28.09 EL 70:38:47.66
  star 4 74.8920  2.83 RA 00:13:14.15 DEC +15:11:01  AZ 120:06:16.94 EL 60:27:29.42

The original info about centroiding:

Acquire client: slew to 6BetAri 1.911 20.808

Image stats             axes:352,288  min:15 max:247 mean:44.225043 median:44 dev:6.613 var:43.726 thresh:63 
Image subtraction stats axes:352,288  min:10 max:242 mean:41.924006 median:42 dev:6.439 var:41.463
Subtracted image stats  size:101376   min:0 max:178 mean:5.957692 median:5 dev:5.228 var:27.331
Centroid: 144,78
Acquire client, pass 1  dist: 0.332192 (deg)  apply X acquisition correction 11,-52 (pix) X:4.125 Y:0.000 (arcmin)
Acquire client: modified scales 1.000,1.000  22.500,22.500
Acquire client, pass 1  apply Y acquisition correction 11,-52 (pix)  X:0.000 Y:-19.500 (arcmin)
...

Issues

• At high LBT elevations (75+), the mount doesn't respond to small moves up, so auto-acq cannot acquire.
• It needs a way for the operator to force it to move to the next star. If measuring struggles, auto-acq will stick with the top of the list because it only moves on when it cannot acquire. If it acquires OK and starts measuring, it doesn't know that measuring can struggle.
  Maybe this could be an acquiring state in the server. auto-acquire could move to the next star if DIMM doesn't get to measuring and gets stuck in acquiring.
• How can we pass mount exceptions to the auto-acq client? It doesn't know when the slew fails. It needs to know to move to another star to get out of mount failure conditions.
  Maybe we need an exception state for the mount.
• See also notes here: DIMMSoftwareUpgrades#Current_working_issues

Troubleshooting

• can use the centerStar star log messages to determine how well centroiding is doing
• the X,Y pixel locations on the web cam match the FITS file, so it should be easy to change the desired pixel locations in config, if necessary. There's a program to take the web image and convert it to FITS.
  see Server/Test/createFITS.cpp
createFITS 20160407162530-webimage.jpg     will create a file called 20160407162530-webimage.fits
  Very slight changes in web cam pixel locations make a huge difference - the webcam is 45 arcsec/pixel, the DIMM cam is 0.34 arcsec/pixel.
• exposure times are set by providing the number of horizontal-line-periods (~90 usec each); we're using 15ms for 200x200 when measuring and 25ms for acquisition (full frame)

  command	H lines	exp time
  0x36	54	5ms	default
  0xa5	165	15ms	measuring
  0x114	276	25ms	acquisition
  0x414	1044	94ms	max setting

End of main operations info, the following is testing info, initial design problems, etc.

---

Testing

See DIMMAutoAcqTesting for details.

Centroiding Notes

The web cam generates a jpg file. The easiest approach to centroiding was to get a FITS image of the web cam file.
I installed a newer version of ImageMagick on the DIMM machine and tried out the API. It's easy to generate a FITS file from that, and we have DIMM standalone code that uses its centroiding on FITS files. In the auto-acquisition testing, we've seen that It's using the centroiding code that the DIMM camera uses, except we modified the threshold value to be 2.7*standard-deviation-image instead of 3.0 (still provides 99.3% confidence level). We also added a "dark" image subtraction. We've captured a blank web image, translated to FITS, and it is subtracted, pixel-by-pixel, from the incoming image.

See DIMM Centroiding Notes .. Algorithm for some notes on the original DIMM centroiding algorithm.

JMH says the sky background is 100X different between a moonlit night and a dark night. Somehow, we need to adjust for this.

On the night of 20160406, auto-acquisition was picking up basically hot pixels in the image data. There is nothing close enough to a star in the background images. (See notes/screenshots/images in /home/ksummers/dimm/troubleshooting/auto-acquire/20160406) Doug suggested we use one of the images to add to our current background image, to pick up these extra hot pixels. I created a standalone executable that creates this "added together" FITS file.
You run it giving it the file you want added to the current dark image (hard-coded in the main program) and it produces a time-stamped dimm-dark-web.fits file:

cd /home/dimmuser/3.1/Client
g++ -g -I ../ -I/usr/include -L/usr/lib  dimmAddDarks.cpp -o dimmAddDarks -lcfitsio -lm
./dimmAddDarks ../../dimm-acq-fits/20160406/20160406030401-subtractedimage.fits
      .. produces
20160406235058-dimm-dark-web.fits 

Design

Standalone Client

Initial thoughts are to use the web cam to centroid and move the mount automatically rather than the operators using the handpaddle and the target.

Loop forever
   if LBT tracking && DIMM not measuring

      Loop while !measuring and star<NStars and not cntl-C

        for CURRENT star in list within N brightest stars within D of DIMM, starting with closest
           DIMM->slewMount to particular star in list (this interface exists ... slewMount (ra,dec,dist,mag,star) )
            sleep just a second so that we can see the mount tracking
           if ( DIMM->onTarget )
             grab web image   ( wget http://dimm-webcam.mountain.lbto.org/jpg/image.jpg )
             convert image.jpg to FITS  (installed ImageMagick-6.9.3-4 on dimm machine and compiled (no tiff) to make this work)
             centroid
             calculate offset: x,y
             DIMM->moveMount ( x,y )
             DIMM->startSpiral
             if ( !DIMM->measuring )     if it's not measuring, it failed
                 try next star in list for only the top N stars
      end loop

   else (LBT off target or we're already measuring
     sleep 

end loop

Integrated into the Server

• it's not as simple as a new thread (like the camera thread, for instance) because it needs the info from the async update - the star list
• where do we get the state info? LBT tracking / DIMM measuring / mount tracking ? I don't want an attribute for each of the mount, LBT, ...
  cannot use the dimm settings because it is just a copy, it's not updated, I think - this is why it really needs to be a singleton, updated all the time
• how do we call the server back? need to start measuring, start spiral
• can I use the service methods or do I have to use the mount directly?
• the way the other threads get their config is from the globally (but passed around) dimm settings

Notes

Command interfaces to the DIMM that are not already there:

• onTarget - is DIMM not slewing/moving/etc? There are three moving states ( moving,searching,slewing ) - I think I can just use tracking
  Does the mount fall out of tracking if LBT stops tracking? I think so - maybe I don't need LBT info.
  But, the mount also goes out of tracking when guide corrections are applied - in slew.
• moveMount (x,y) - currently only move to ra/dec is supported done, need to calculate pixel scale for web cam
• foundCentroid - maybe we don't need this, we can just make spiral always start measuring if it finds something - why else would you want to spiral?
• getStars - some kind of interface to get all the stars the user would see on the move mount GUI
  Every 30secs, the GUI updates the star list from m_ServerSettings.dimmSet.catalogStars which is being written from the server as often as runInfoService_async is run, as long as the mount is connected. (Sleeps less than half a second.)
  Since this structure is shared currently between client and server, can we share with another client? Make sure we don't pay attention if the mount is not connected.

Other modifications:

• want the sorting on the starlist to be whatever the operators typically choose - do they go by magnitude or closest? maybe they don't always choose the closest, but the closest with the lowest magnitude   done - there was already a merit function using zenith distance and magnitude with configurable multipliers. I modified it to use LBT-to-DIMM distance and we played with the multipliers in a spreadsheet to give us the weighting we like. (June-2016)
• spiral search should start looking in its current position, don't move   done
• spiral does not currently go to measuring, but it does do the centerStar   done
• any reason not to connect to all the devices (mount and camera) on startup? rather than force the user to connect?   done
  could make this configurable so that if you really only want to run the software, you could set it as admin or something
  There's already a Dimm.autoMode configuration item that is always set to "automatical". It's the flag manual in dimm settings. Used to setROI in start measuring if the camera is using full frame and in applySettingsCamera when changing something - it's set here. If you changed the ROI via the GUI camera settings, manual would get set to true unless you reset to full-frame.
• shouldn't go back to home when LBT is not tracking   done

Questions:

• do I need some sleeps in there and checking for move done? or are the calls blocking? yes - need some sleeps because we are using the info service (2x/second) to tell us the states
• do I need a different port for this client?? I think maybe not, it seems Ice likes to share connections (https://doc.zeroc.com/display/Doc/Connection+Management+in+Ice)
• how does searching in DIMM settings differ from mount settings moving or slewing ? Do I need it?
• what does the setPointingError do in the mount code, do I need to do that?
• see DIMMTestingDec2012#Spiral_Search for details on the spiral search
• always checking the LBT is on-target, to jump out of measuring, spiraling (see above, maybe the mount does this for me)
• hardest thing might be the implementation of the move (x,y) command
  No - it should be just like the guide corrections done in DimmCameraThread::run using distance in pixels:

                               double distanceX = ( centerStarsX - centerFrameX ) * m_DimmSettings.pixelscale / 3600.;
                                double distanceY = ( centerStarsY - centerFrameY ) * m_DimmSettings.pixelscale / 3600.;
                                m_Mount->slew ( currentPointing.upDown + distanceX, currentPointing.leftRight + distanceY, false );
                                sprintf( buf, "Apply guide correction distanceX:%f distanceY:%f (arcmin)",
                                         distanceX*60.0, distanceY*60.0 );
 

The other use of this slew command is in the spiral search:

        double udSize = camSet.cameraSize.width * m_DimmSettings.pixelscale * m_DimmSettings.spiralSearchSize / 3600.; // [degree]
        double lrSize = camSet.cameraSize.height * m_DimmSettings.pixelscale * m_DimmSettings.spiralSearchSize / 3600.; // [degree]

        int j=1;
        int c=1;
        int dx, dy;

        //do spiral search of size 8
        for ( int i=1 ; i<16 ; i++ )
        {
            CoordinateInfo currentPointing = m_Mount->position();
                ... set up dx,dy based on which way we want to go this loop
            for ( int b=1; b<j ; b++ )
            {
                tmpUD = currentPointing.upDown + sgn ( dy ) * b * udSize;
                tmpLR = currentPointing.leftRight + sgn ( dx ) * b * lrSize;

                //Calculate the final position to go, with flag that says we're not acquiring yet
                m_Mount->slew ( tmpUD, tmpLR, false );
         .............

---

IDL Notes

Initially, we thought we'd do image processing of the web image directly. It is written as a JPG, but John gave me sohttps://www.as.arizona.edu/me IDL code that reads GIF:

                   IDL> read_gif,'image.gif',webimage
                    IDL> help, webimage
                    WEBIMAGE        BYTE      = Array[352, 288]
                    IDL> read_jpeg,'image.jpg',webjpg
                    % Loaded DLM: JPEG.
                    IDL> help,webjpg
                    WEBJPG          BYTE      = Array[3, 352, 288]

On the mountain, there is an astron lib in lbcobs. To use the cntrd function from there, you need to give it where you think the centroid is (how useful is that?) I copied a DIMM acquisition image (two stars, maybe that's a problem) into a gif using ImageMagick. It came out as a 1388x1024 pixel gif file. In ds9, the brighter of the two centroids looks to be about 663, 665.

Here's my imstat.pro file

 read_gif,'dimm-acq.gif',webimage
 print,"dimm-acq.gif..."

 min=10
 max=0
 avg=0.0
 sum=0.0
 dims=size(webimage,/DIMENSIONS)
 for i=0,(dims[0]-1) do begin
   for j=0,(dims[1]-1) do begin
     if (min gt webimage[i,j]) then min=webimage[i,j]
     if (webimage[i,j] gt max) then max=webimage[i,j]
     if (webimage[i,j] lt 0) then print, webimage[i,j]
     sum = sum + webimage[i,j]
   end
 end
 ;;print, "sum is ", sum
 avg = sum / (dims[0]*dims[1])
 print, "image size is ",dims[0],"  by",dims[1]
 print, "min is ", min
 print, "max is ", max
 print, "avg is ", avg

 cen=centroid(webimage)
 print, "center of mass is ", cen[0],cen[1]
 
 total=com2(webimage)
 print, "com2 result is ", total[0],total[1]
end

setenv IDL_PATH +/lbt/astronomy/idl/lib:+/home/lbcobs/LBCFPIA/lbcfpia/lib/astron

IDL> .run imstat  
% Compiled module: $MAIN$.
dimm-acq.gif...
image size is         1388  by        1024
min is    0
max is  160
avg is      0.827264
% Compiled module: CENTROID.
% Compiled module: DATA_CHK.
center of mass is       680.453      514.563
IDL> exit
[telescope@obs3 ~/ksummers]$ idl
IDL Version 8.1 (linux x86 m32). (c) 2011, ITT Visual Information Solutions
Installation number: 223182.
Licensed for use by: LBTO-University of Arizona

IDL> .run imstat
% Compiled module: CENTROID.
% Compiled module: $MAIN$.
% Loaded DLM: GIF.
dimm-acq.gif...
image size is         1388  by        1024
min is    0
max is  160
avg is      0.827264
center of mass is       680.453      514.563
IDL> .run imstat
% Compiled module: CENTROID.
% Compiled module: COM2.
% Compiled module: $MAIN$.
dimm-acq.gif...
image size is         1388  by        1024
min is    0
max is  160
avg is      0.827264
center of mass is       680.453      514.563
com2 result is       680.453      514.563
IDL> exit

I don't know why it's finding this spot, if I print all the pixels over 10, for instance, it's obvious the pixels around 660-670 (in both dimensions) are high - over 100 - the max is at 662,664.

In IDL, looking at the gif file generated from the web cam:

	min	max	avg
bright daytime image	0	170	97	Loads of pixels over 100
acq image with star	0	119	24
daytime image dark dome	0	178	38