PAN015: Wildwood Institute for STEM Research and Development, WISRD (Wildwood School)

Hi @jlumbres and @wtgee,
Our board does not appear to have a marking on it. I think we might have been the first to test the interface board after the builder of it, and from looking in the PANOPTES google drive folder we have a different board layout. I was able to trace connections in my previous post from an image of the control board layout that I could only find in our team’s google drive folder.

It’s looking like our board is the only one with this issue.

We found the process IDs on the camera using lsusb -g and looking for gphoto2 processes. I tried running setup_pocs within the pocs shell but got this error:

POCS > setup_pocs
Traceback (most recent call last):
  File "/var/panoptes/POCS/scripts/pocs-shell.py", line 850, in <module>
    PocsShell().cmdloop()
  File "/opt/conda/lib/python3.7/cmd.py", line 138, in cmdloop
    stop = self.onecmd(line)
  File "/opt/conda/lib/python3.7/cmd.py", line 217, in onecmd
    return func(arg)
  File "/var/panoptes/POCS/scripts/pocs-shell.py", line 166, in do_setup_pocs
    scheduler = create_scheduler_from_config()
  File "/var/panoptes/POCS/pocs/scheduler/__init__.py", line 56, in create_scheduler_from_config
    default_horizon=default_horizon.value
AttributeError: 'int' object has no attribute 'value'

I looked in our config file and we have a scheduler file specified, and it does exist in the targets folder. Is this an issue with our config file?

Hi @zacharyt,

I think we saw this same error, and fixed it with some adjustments to our pocs_local.yaml file. An older version of the config did not require units being defined for several parameters, but the new one does. Does the top of your pocs_local.yaml look like this (obviously with a different name, id, and values), specifically with “deg” being included on ‘horizon’ and ‘observe_horizon’ (and on latitude/longitude, as well as “m” on elevation too):

name: UA PANOPTES Unit
pan_id: PAN010
location:
  name: Steward Observatory
  latitude: 32.233 deg   # Degrees
  longitude: -110.9484 deg   # Degrees
  elevation: 728.2 m  # Meters
#  utc_offset: -7.00   # Hours
  horizon: 30.0 deg # Degrees
  observe_horizon: -18.0 deg # Degrees

If not, try adding that. It should help Python interpret it correctly, not as an integer but rather as an astropy (I think) object.

1 Like

@atrodack thanks for the fix!
We got PAN015 moving for the first time!

Unfortunately, when we entered go_home the unit tried moving past the physical constraints of the mount. There was a noise after it tried rotating to far, and I pulled the plug on the mount shortly after when the camera box was about to collide with our tripod. I am assuming this happened because the unit has a starting position that it uses a starting point to base its other movements off of. @nem @wtgee is this correct? If so, what is that starting position? Is it the safe position mentioned in the documentation (where the camera lenses are facing down towards the ground )?

Also, we are interested in doing a test observation of an exoplanet later this week or early next week if indoor tests go well. Do we need a special scheduler file or can we just use the tess_sectors_north.yaml file? How can we tell where the mount will point to observe an already known transit? (I am curious because there is a large building next to our school that blocks a large portion of the sky)

Thanks again to @wtgee, @atrodack, and @tmcook for the help with getting PAN015 so close to deployment.

1 Like

@zacharyt

go_home assumes the mount is in the park position, which is indeed when the camera lenses face toward the ground. @wtgee demonstrates it correctly in the second image of this post on your thread.

In our experience with PAN010, we have had to shut off the mount to avoid collisions, or we’ve lost connection to it while POCS is still running for one reason or another, so we’ve run into the issue where re-running POCS seems to use the last known mount position as the park position. Typically we’ll just rotate the mount to a position where it can safely travel to “home”, then once it’s there, we move it to where it actually should be. Then calling park actually puts the mount into the park position, or close enough anyway since we’ve seen that our mount movement rate may be a little slower than average.

Here is an exoplanet transit tracking tool. It’s pretty self explanatory if you’re used to some astronomical terms and definitions. One way to figure out which transits you can try to track is to identify the star magnitudes your cameras can get a good signal from by taking different exposure level images of known bright objects and using a program like stellarium to identify some of the dimmer, yet still visible stars. Then you can tell which magnitude stars to go for above the sky background/light pollution at various exposure times. Another potentially easier option is to use the rule of thumb that 8-12 V magnitude stars should be visible and just go for an easily detectable (read: big dip in the light curve), upcoming transit informed by the transit tool. In either case, you’ll need to create a list of targets similar to simple.yaml or use that itself.

If I recall correctly, PAN012 tracked a fairly easy transit at first, so you can try and do the same things that they posted in their thread. In any case you’ll need to find a suitable place for your unit to see a transit of interest for the entire duration plus, ideally, time before and after, and spend time polar-aligning your unit so that the data can actually be reduced to a light curve that shows a transit happening.

Justin

Thanks for the response @jmk1729.
I am a little confused about what unpark, park and go_home do. It was my understanding that unpark allows the mount to move, park stops the mount from moving and go_home moves the unit to the position where the cameras are facing towards the ground.

In your post, you mention both a “park” position and a “home” position. Are these the same position? If not, what are the park and home positions?

Unfortunately our unit has decided to stop working today. At first, the unit would not unpark and gave an error, I believe it said: Problem Unparking: None. I tried fixing this by first parking the mount and then unparking it but this did not work. I tried power cycling the mount and then the unit. Then when trying to use the pocs-shell I could not setup-pocs because the camera’s could not be detected. I used lsof -g | grep gmain to see all of the gmain process and there were around 30 gmain processes. When running docker ps we now see a seemingly random docker container called hopeful_feynman, and the paws container is gone.

@wtgee Do you know what the hopeful_feynman container is?

To my knowledge, we haven’t encountered the problem you are describing. I can however, define park, unpark and go_home.

home is defined as the position where the celestial pole of your hemisphere is in the field of view of your cameras. More precisely you can say it the position of the mount where the results of polar_alignment_test indicate negligible differences between its axis of rotation and the solved celestial pole - in our case, the north star Polaris. This gives the POCS observatory a reference to move to other objects in the night sky, as is the case if you’ve used other telescope tracking mounts.

go_home assumes you’re in the park position, which is defined as the safe position of the mount during the day time or when there is cloud coverage overhead. From the picture in the thread I linked to, it’s when the RA axis is horizontal such that the head unit is rotated to face the east, and the DEC axis is rotated so that the camera lenses in the head unit are looking downward.

So go_home travels between the park position and its celestial pole reference. unpark works mostly as you describe - it allows the mount to move if it is in park.

Good luck with the container issues.

The mount is moving predictably after we manually moved it to the correct position after go_home is called. We were also able to achieve the same behavior by calling park and rotating the mount manually to the correct park position. Thanks for the advice!

This also seems to be the case for our unit. The mount rotates slightly slower than the software expects, and as a result the head unit is not parallel with the ground. I was looking in some of the pocs-shell python scripts and they appear to tell the mount to move in a certain direction for a certain amount of time. We should be able to edit the times to get more accurate turning (or update the pocs-shell to have a calibration process for future builders).

Our docker container problem has seemed to go away after a full system reboot.

We are getting an error during the polar_alignment_test. In the POCS shell we see:

WARNING: AstropyDeprecationWarning: astropy.extern.six will be removed in 4.0, use the six module directly if it is still needed [astropy.extern.six]
Failed to download IERS A bulletin: <urlopen error [Errno 104] Connection reset by peer>
Welcome to POCS Shell! Type ? for help
POCS > setup_pocs simulator=power simulator=night simulator=weather
Using simulators: ['power', 'night', 'weather']
POCS > unpark
POCS > polar_alignment_test
Moving to home position
Performing polar rotation test
At home position, taking 30 sec exposure
/var/panoptes/images/drift_align/20191122T181623/pole_cam01.cr2: No such file or directory
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/var/panoptes/panoptes-utils/panoptes/utils/images/cr2.py", line 164, in cr2_to_pgm
    if subprocess.check_call(cmd_list) == 0:
  File "/opt/conda/lib/python3.7/subprocess.py", line 347, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/usr/bin/dcraw', '-t', '0', '-D', '-4', '/var/panoptes/images/drift_align/20191122T181623/pole_cam01.cr2']' returned non-zero exit status 1.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/conda/lib/python3.7/threading.py", line 917, in _bootstrap_inner
    self.run()
  File "/opt/conda/lib/python3.7/threading.py", line 1166, in run
    self.function(*self.args, **self.kwargs)
  File "/var/panoptes/POCS/pocs/camera/canon_gphoto2.py", line 191, in _poll_exposure
    self._readout(*readout_args)
  File "/var/panoptes/POCS/pocs/camera/canon_gphoto2.py", line 161, in _readout
    fits_path = cr2_utils.cr2_to_fits(cr2_path, headers=info, remove_cr2=False)
  File "/var/panoptes/panoptes-utils/panoptes/utils/images/cr2.py", line 58, in cr2_to_fits
    pgm = read_pgm(cr2_to_pgm(cr2_fname), remove_after=True)
  File "/var/panoptes/panoptes-utils/panoptes/utils/images/cr2.py", line 169, in cr2_to_pgm
    raise error.InvalidSystemCommand(msg="File: {} \n err: {}".format(cr2_fname, err))
panoptes.utils.error.InvalidSystemCommand: InvalidSystemCommand: File: /var/panoptes/images/drift_align/20191122T181623/pole_cam01.cr2 
 err: Command '['/usr/bin/dcraw', '-t', '0', '-D', '-4', '/var/panoptes/images/drift_align/20191122T181623/pole_cam01.cr2']' returned non-zero exit status 1.

/var/panoptes/panoptes-utils/panoptes/utils/images/__init__.py:105: UserWarning: File doesn't exist, can't make pretty: /var/panoptes/images/drift_align/20191122T181623/pole_cam01.cr2
  warn("File doesn't exist, can't make pretty: {}".format(fname))
Doing rotation test
Rotating to east
/var/panoptes/images/drift_align/20191122T181623/rotation_east_cam01.cr2: No such file or directory
Exception in thread Thread-2:
Traceback (most recent call last):
  File "/var/panoptes/panoptes-utils/panoptes/utils/images/cr2.py", line 164, in cr2_to_pgm
    if subprocess.check_call(cmd_list) == 0:
  File "/opt/conda/lib/python3.7/subprocess.py", line 347, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/usr/bin/dcraw', '-t', '0', '-D', '-4', '/var/panoptes/images/drift_align/20191122T181623/rotation_east_cam01.cr2']' returned non-zero exit status 1.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/conda/lib/python3.7/threading.py", line 917, in _bootstrap_inner
    self.run()
  File "/opt/conda/lib/python3.7/threading.py", line 1166, in run
    self.function(*self.args, **self.kwargs)
  File "/var/panoptes/POCS/pocs/camera/canon_gphoto2.py", line 191, in _poll_exposure
    self._readout(*readout_args)
  File "/var/panoptes/POCS/pocs/camera/canon_gphoto2.py", line 161, in _readout
    fits_path = cr2_utils.cr2_to_fits(cr2_path, headers=info, remove_cr2=False)
  File "/var/panoptes/panoptes-utils/panoptes/utils/images/cr2.py", line 58, in cr2_to_fits
    pgm = read_pgm(cr2_to_pgm(cr2_fname), remove_after=True)
  File "/var/panoptes/panoptes-utils/panoptes/utils/images/cr2.py", line 169, in cr2_to_pgm
    raise error.InvalidSystemCommand(msg="File: {} \n err: {}".format(cr2_fname, err))
panoptes.utils.error.InvalidSystemCommand: InvalidSystemCommand: File: /var/panoptes/images/drift_align/20191122T181623/rotation_east_cam01.cr2 
 err: Command '['/usr/bin/dcraw', '-t', '0', '-D', '-4', '/var/panoptes/images/drift_align/20191122T181623/rotation_east_cam01.cr2']' returned non-zero exit status 1.

/var/panoptes/panoptes-utils/panoptes/utils/images/__init__.py:105: UserWarning: File doesn't exist, can't make pretty: /var/panoptes/images/drift_align/20191122T181623/rotation_east_cam01.cr2
  warn("File doesn't exist, can't make pretty: {}".format(fname))
Moving back to home
Solving celestial pole image
Unable to solve pole image: FileNotFoundError(2, 'No such file or directory')
Will proceeed with rotation image but analysis not possible
Starting analysis of rotation image
nable to process rotation image: [Errno 2] No such file or directory: '/var/panoptes/images/drift_align/20191122T181623/rotation_east_cam01.fits'
Done with polar alignment test
POCS >

What I believe is the important part of the pocs-shell log file:

I1122 18:16:23.619              messaging.py:185] PANCHAT Moving to home position
D1122 18:16:26.135                  mount.py:595] Slewing to home, sleeping for 3 seconds
D1122 18:16:31.151                  mount.py:595] Slewing to home, sleeping for 3 seconds
D1122 18:16:36.167                  mount.py:595] Slewing to home, sleeping for 3 seconds
D1122 18:16:41.184                  mount.py:595] Slewing to home, sleeping for 3 seconds
I1122 18:16:46.198              messaging.py:185] PANCHAT Performing polar rotation test
I1122 18:16:48.715              messaging.py:185] PANCHAT At home position, taking 30 sec exposure
D1122 18:16:48.718                 camera.py:361] Taking 30.0 s exposure on Cam01: /var/panoptes/images/drift_align/20191122T181623/pole_cam01.cr2
D1122 18:17:28.746          canon_gphoto2.py:160] Converting CR2 -> FITS: /var/panoptes/images/drift_align/20191122T181623/pole_cam01.cr2
E1122 18:17:28.767                  error.py:013] InvalidSystemCommand: File: /var/panoptes/images/drift_align/20191122T181623/pole_cam01.cr2
 err: Command '['/usr/bin/dcraw', '-t', '0', '-D', '-4', '/var/panoptes/images/drift_align/20191122T181623/pole_cam01.cr2']' returned non-zero exit status 1.
D1122 18:17:28.768          canon_gphoto2.py:193] Setting exposure event for Cam01
I1122 18:17:28.779              messaging.py:185] PANCHAT Doing rotation test
D1122 18:17:31.295                  mount.py:659] Move command: move_west
D1122 18:17:31.297                  mount.py:663] Moving west for 11.0 seconds.
D1122 18:17:44.815                  mount.py:668] 13.515970000004529 seconds passed before stop
D1122 18:17:45.320                  mount.py:670] 14.020864000005062 seconds passed total
D1122 18:17:45.320                  mount.py:678] Stopping movement
I1122 18:17:45.822              messaging.py:185] PANCHAT Rotating to east
D1122 18:17:45.825                 camera.py:361] Taking 25.0 s exposure on Cam01: /var/panoptes/images/drift_align/20191122T181623/rotation_east_cam01.cr2
D1122 18:17:45.847                  mount.py:659] Move command: move_east
D1122 18:17:45.848                  mount.py:663] Moving east for 21.0 seconds.
D1122 18:18:09.377                  mount.py:668] 23.525567000010383 seconds passed before stop
D1122 18:18:09.880                  mount.py:670] 24.0310200000188 seconds passed total
D1122 18:18:09.880                  mount.py:678] Stopping movement
D1122 18:18:20.854          canon_gphoto2.py:160] Converting CR2 -> FITS: /var/panoptes/images/drift_align/20191122T181623/rotation_east_cam01.cr2
E1122 18:18:20.873                  error.py:013] InvalidSystemCommand: File: /var/panoptes/images/drift_align/20191122T181623/rotation_east_cam01.cr2
 err: Command '['/usr/bin/dcraw', '-t', '0', '-D', '-4', '/var/panoptes/images/drift_align/20191122T181623/rotation_east_cam01.cr2']' returned non-zero exit status 1.
D1122 18:18:20.873          canon_gphoto2.py:193] Setting exposure event for Cam01
I1122 18:18:22.396              messaging.py:185] PANCHAT Moving back to home
D1122 18:18:24.914                  mount.py:595] Slewing to home, sleeping for 3 seconds
D1122 18:18:29.931                  mount.py:595] Slewing to home, sleeping for 3 seconds
D1122 18:18:34.948                  mount.py:595] Slewing to home, sleeping for 3 seconds
I1122 18:18:39.966              messaging.py:185] PANCHAT Solving celestial pole image
I1122 18:18:39.970              messaging.py:185] PANCHAT Starting analysis of rotation image
I1122 18:18:39.973              messaging.py:185] PANCHAT Done with polar alignment test

I also found that polar alignment tests have their own log file. Ours only have one line, and it looks like it is being caused by another bad config file:

I1122 18:14:40.684                 logger.py:281] ****************************** Starting PanLogger ******************************
I1122 18:14:40.759                 client.py:056] Problem with get_config: ConnectionError(MaxRetryError("HTTPConnectionPool(host='0.0.0.0', port=6563): Max retries exceeded with url:  /get-config  (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f9a05b3fe10>: Failed to establish a new connection: [Errno 111] Connection refused'))"))

When we first tried this we did not have a drift_align directory in $PANDIR/images, however I manually made it later.@wtgee Is this a problem with a config file or our file structure?

Hey @zacharyt, glad things sort of are working out.

Ca you check and see if the following file was actually created? If the .fits is not there then the .cr2 might be.

Have you tried just manually taking pictures from the command line, outside pocs-shell? You can take bias images with something like the following:

(panoptes-env) ➜  POCS git:(docker) ✗ gphoto2 --auto-detect

Model                          Port                                            
----------------------------------------------------------
Canon EOS 100D                 usb:002,057     
Canon EOS 100D                 usb:002,056     

(panoptes-env) ➜  POCS git:(docker) ✗ scripts/take_bias.sh usb:002,057

Taking bias frames on port usb:002,057: bias-%Y%m%d-%H%M%S.cr2
New file is in location /capt0000.cr2 on the camera                            
Saving file as bias-20191123-101537.cr2
Deleting file /capt0000.cr2 on the camera
Done with bias                            
                                     
(panoptes-env) ➜  POCS git:(docker) ✗ scripts/take_bias.sh usb:002,056

Taking bias frames on port usb:002,056: bias-%Y%m%d-%H%M%S.cr2
New file is in location /capt0000.cr2 on the camera                            
Saving file as bias-20191123-101544.cr2
Deleting file /capt0000.cr2 on the camera
Done with bias                            

There is nothing in the drift_align folder. When I use the take_bias.sh script, we are unable to take pictures and get this output:

Taking bias frames on port usb:001,029: bias-%Y%m%d-%H%M%S.cr2

*** Error ***
Choice 52 not found within list of choices.
*** Error (-2: 'Bad parameters') ***

For debugging messages, please use the --debug option.
Debugging messages may help finding a solution to your problem.
If you intend to send any error or debug messages to the gphoto
developer mailing list <gphoto-devel@lists.sourceforge.net>, please run
gphoto2 as follows:

    env LANG=C gphoto2 --debug --debug-logfile=my-logfile.txt --port=usb:001,029 --set-config-index shutterspeed=52

Please make sure there is sufficient quoting around the arguments.

That’s odd. What kind of camera do you have?

That’s just trying to set the shortest exposure time, which should be the same for most of our cameras. You can see all the choices with, e.g.

gphoto2 --port usb:002,057 --get-config shutterspeed

The take_bias.sh script takes a shutter speed as a parameter but it’s awkward because you first have to specify the filename. You could edit line 34 of the script to change the default shutter speed to whatever index choice is last from the above gphoto2 command.

We have two cannon EOS 100D.

Changing the script line made the take_bias.sh script work. The choice index for shutterspeed was
from 0 to 51, not 52. It seems like gphoto2 may have shifted from a choice of 1-52 to a choice of 0-51.

I’m currently on Thanksgiving break, so I don’t have physical access to the unit to test the polar alignment again. (Not that confident of our mounts movement)

Does the pocs-shell take images using take_bias.sh or do I need to also edit another script somewhere else for the change to apply in the pocs-shell?

Can you post your gphoto2 --version:

This version of gphoto2 is using the following software versions and options:
gphoto2         2.5.23         gcc, popt(m), exif, no cdk, no aa, jpeg, no readline
libgphoto2      2.5.23         all camlibs, gcc, ltdl, EXIF
libgphoto2_port 0.12.0         iolibs: disk ptpip serial usb1 usbdiskdirect usbscsi, gcc, ltdl, USB, serial without locking

No, POCS itself uses the $POCS/scripts/take_pic.sh script, and you can test that too. It just doesn’t work well for exposures under 1 second. The take_bias.sh is just convenient for taking really short exposures to test that the camera is indeed connected and working; if it works there it should work in POCS. For take_pic.sh we don’t use the 1-52 numbering choices but expose “manually” to mimic holding down the shutter button.

Our version is:

This version of gphoto2 is using the following software versions and options:
gphoto2         2.5.15         gcc, popt(m), exif, cdk, aa, jpeg, readline
libgphoto2      2.5.16         all camlibs, gcc, ltdl, EXIF
libgphoto2_port 0.12.0         iolibs: disk ptpip serial usb1 usbdiskdirect usbscsi, gcc, ltdl, USB, serial without locking

This is clearly out of date. It looks like the gphoto2 index was shifted to 52 for readability later. (The opposite order of what I suggested)

I tested take_pic.sh and it doesn’t seem to be working. We get no error messages however an image is not created in the specified location (/var/panoptes/images/test.cr2). The output of scripts/take_pic.sh usb:001,030 5 /var/panoptes/images/test.cr2 from the $POCS directory is:

Taking picture
PORT = usb:001,030
TIME = s
FILE = /var/panoptes/images/test.cr2
Waiting for 5 seconds for events from camera. Press Ctrl-C to abort.
UNKNOWN PTP Property d105 changed
UNKNOWN PTP Property d108 changed
UNKNOWN PTP Property d106 changed
UNKNOWN PTP Property d107 changed
UNKNOWN PTP Property d109 changed
UNKNOWN PTP Property d10a changed
UNKNOWN PTP Property d10b changed
UNKNOWN PTP Property d10c changed
UNKNOWN PTP Property d10d changed
UNKNOWN PTP Property d10e changed
UNKNOWN PTP Property d10f changed
UNKNOWN PTP Property d11b changed
UNKNOWN PTP Property d114 changed
UNKNOWN PTP Property d116 changed
UNKNOWN PTP Property d119 changed
UNKNOWN PTP Property d110 changed
UNKNOWN PTP Property d101 changed
UNKNOWN PTP Property d102 changed
UNKNOWN PTP Property d103 changed
UNKNOWN PTP Property d104 changed
UNKNOWN PTP Property d11d changed
UNKNOWN PTP Property d111 changed
UNKNOWN PTP Property d112 changed
UNKNOWN PTP Property d113 changed
UNKNOWN PTP Property d17c changed
UNKNOWN PTP Property d17d changed
UNKNOWN PTP Property d17e changed
UNKNOWN PTP Property d120 changed
UNKNOWN PTP Property d121 changed
UNKNOWN PTP Property d122 changed
UNKNOWN PTP Property d156 changed
UNKNOWN PTP Property d150 changed
UNKNOWN PTP Property d151 changed
UNKNOWN PTP Property d152 changed
UNKNOWN PTP Property d153 changed
UNKNOWN PTP Property d154 changed
UNKNOWN PTP Property d155 changed
UNKNOWN PTP Property d160 changed
UNKNOWN PTP Property d161 changed
UNKNOWN PTP Property d162 changed
UNKNOWN PTP Property d11c changed
UNKNOWN PTP Property d1a0 changed
UNKNOWN PTP Property d1a1 changed
UNKNOWN PTP Property d1a8 changed
UNKNOWN PTP Property d1a7 changed
UNKNOWN PTP Property d1ab changed
UNKNOWN PTP Property d1b0 changed
UNKNOWN PTP Property d1b1 changed
UNKNOWN PTP Property d1b2 changed
UNKNOWN PTP Property d1b3 changed
UNKNOWN PTP Property d1b4 changed
UNKNOWN PTP Property d1b5 changed
UNKNOWN PTP Property d1b6 changed
UNKNOWN PTP Property d1a9 changed
UNKNOWN PTP Property d146 changed
UNKNOWN PTP Property d1ac changed
UNKNOWN PTP Property d1aa changed
UNKNOWN PTP Property d11e changed
UNKNOWN PTP Property d11f changed
UNKNOWN PTP Property d1d9 changed
UNKNOWN PTP Property d1ba changed
UNKNOWN PTP Property d1cc changed
UNKNOWN PTP Property d1bc changed
UNKNOWN PTP Property d1b8 changed
UNKNOWN PTP Property d1d3 changed
UNKNOWN PTP Property d1d8 changed
UNKNOWN PTP Property d1b7 changed
UNKNOWN PTP Property d1cb changed
UNKNOWN PTP Property d1db changed
UNKNOWN PTP Property d1dc changed
UNKNOWN PTP Property d1a3 changed
UNKNOWN PTP Property d1a4 changed
UNKNOWN PTP Property d1df changed
UNKNOWN PTP Property d1bd changed
UNKNOWN PTP Property d1c1 changed
UNKNOWN PTP Property d1c0 changed
UNKNOWN PTP Property d1bf changed
UNKNOWN PTP Property d1c4 changed
UNKNOWN PTP Property d1c2 changed
UNKNOWN PTP Property d1c5 changed
UNKNOWN PTP Property d194 changed
UNKNOWN PTP Property d195 changed
UNKNOWN PTP Property d196 changed
UNKNOWN PTP Property d197 changed
UNKNOWN PTP Property d198 changed
UNKNOWN PTP Property d1dd changed
UNKNOWN PTP Property d1c7 changed
UNKNOWN PTP Property d199 changed
UNKNOWN PTP Property d138 changed
UNKNOWN PTP Property d139 changed
UNKNOWN PTP Property d13a changed
UNKNOWN PTP Property d13c changed
UNKNOWN PTP Property d13d changed
UNKNOWN PTP Property d14d changed
UNKNOWN PTP Property d19a changed
UNKNOWN PTP Property d19c changed
UNKNOWN PTP Property d1c6 changed
UNKNOWN PTP Property d1c8 changed
UNKNOWN PTP Property d178 changed
UNKNOWN PTP Property d179 changed
UNKNOWN PTP Property d17a changed
UNKNOWN PTP Property d17b changed
UNKNOWN PTP Property d1c9 changed
UNKNOWN PTP Property d19f changed
UNKNOWN PTP Property d137 changed
UNKNOWN PTP Property d1d9 changed
UNKNOWN PTP Property d1d5 changed
UNKNOWN Button 1
UNKNOWN PTP Property d102 changed
UNKNOWN PTP Property d101 changed
UNKNOWN PTP Property d103 changed
UNKNOWN OLCInfo event 0x0010 content 0401013e
UNKNOWN OLCInfo event 0x0020 content 000000000000
UNKNOWN OLCInfo exposure indicator 1,1,0.0 (00000000)
UNKNOWN OLCInfo event 0x0080 content 00000000
UNKNOWN OLCInfo event 0x0400 content 00000000000000
UNKNOWN OLCInfo event 0x0800 content 0000000000080000
UNKNOWN OLCInfo event 0x1000 content 00
UNKNOWN OLCInfo event mask=1fff
UNKNOWN PTP Property d115 changed
UNKNOWN PTP Property d1d0 changed
UNKNOWN PTP Property d1d1 changed
UNKNOWN PTP Property d1af changed
UNKNOWN PTP Property d11b changed
UNKNOWN PTP Property d11c changed
UNKNOWN PTP Property d11b changed
UNKNOWN PTP Property d102 changed
UNKNOWN OLCInfo event mask=2
UNKNOWN PTP Property d102 changed
UNKNOWN OLCInfo event mask=2
UNKNOWN PTP Property d11b changed
UNKNOWN PTP Property d11c changed
UNKNOWN PTP Property d11b changed
UNKNOWN PTP Property d11c changed
UNKNOWN PTP Property d11b changed
UNKNOWN PTP Property d102 changed
UNKNOWN OLCInfo event mask=2
UNKNOWN PTP Property d11b changed
UNKNOWN PTP Property d102 changed
UNKNOWN OLCInfo event mask=2
UNKNOWN PTP Property d102 changed
UNKNOWN PTP Property d102 changed
UNKNOWN OLCInfo event mask=2
UNKNOWN PTP Property d1c3 changed
UNKNOWN Button 32769
UNKNOWN PTP Property d102 changed
UNKNOWN OLCInfo event mask=3
UNKNOWN PTP Property d1c3 changed
UNKNOWN Button 1
UNKNOWN OLCInfo event mask=1
UNKNOWN PTP Property d102 changed
UNKNOWN OLCInfo event mask=2
UNKNOWN PTP Property d101 changed
UNKNOWN PTP Property d1c3 changed
UNKNOWN Button 4
UNKNOWN PTP Property d101 changed
UNKNOWN OLCInfo event mask=5
UNKNOWN Camera Status 1
UNKNOWN PTP Property d11b changed
Waiting for 2 seconds for events from camera. Press Ctrl-C to abort.
UNKNOWN OLCInfo event 0x0010 content 0402013e
UNKNOWN OLCInfo event mask=10
Done with pic

The TIME=s makes me think that I’m not passing in the arguments properly, is my syntax correct? Edit: Syntax is correct, one of the scripts echo messages was incorrect, but this wouldn’t impact functionality. I changed echo "TIME = ${TIME}s" to echo "TIME = ${EXPTIME}s".

I tried to download the current gphoto2 libraries from the gphoto website but ran into some issues. I used wget https://sourceforge.net/projects/gphoto/files/latest/download, and then extracted the file using tar xjf libgphoto2-2.5.23. I then moved the extracted folder to the home directory. The gphoto2 --version output remains the same, which is expected as I should have to remove the previous version. The problem is that I can’t find the location of the previous gphoto2 library.

After digging into installation section in the user manual, I saw that they have the user download an “gphoto2 suite” with many repositories. I also found that the install section(5.3) wasn’t complete, so I did not try that installation method. Should I use this method anyway?

I didn’t see a how to update section in the gphoto2 manual, do you know if there is a better/automatic way of updating gphoto2? If not how do I delete the previous version of gphoto2 and do I have to place the new version in a specific location?

I followed the advanced installation method described in this askubuntu page. In order to get this to work, I had to manually install both libgphoto2 and gphoto2. While we now have the same version you mentioned earlier, we cannot connect to the cameras. I believe this is caused by missing IO Libraries. Our gphoto2 version is:

This version of gphoto2 is using the following software versions and options:
gphoto2         2.5.23         gcc, popt(m), exif, cdk, no aa, jpeg, no readline
libgphoto2      2.5.23         all camlibs, gcc, ltdl, EXIF
libgphoto2_port 0.12.0         iolibs: disk ptpip serial, gcc, ltdl, no USB, serial without locking

libgphoto2_port is missing the iolibs usb1, usbdiskdirect, usbscsi, and USB, which would explain why the cameras cannot be found in gphoto2 --auto-detect or take_pic.sh. I’m trying to find out how to have the installation download these iolibs, but am struggling because of some questionable documentation on the gphoto website. From what I’ve gathered, I should be able to make this change by passing some argument with the ./configure step in the installation. Is this correct?

We now have the same gphoto2 version output as @wtgee. We needed to install the iolibs separately, so that the libgphoto2 library could find them as packages.

Sadly, take_pic.sh is still not working, and has the same behavior as before.

Update:
We solved the issue with take_pic.sh by switching our cameras to manual mode. We now get images from polar_alignment_test in the pocs-shell. We do get an error where we can’t plate solve the image. However I believe this is expected since we took an image indoors, and it looks like PAN012 has been using the jupyter-console to plate solve. For reference the errors in the pocs-shell are:

Solving celestial pole image
Timeout on /var/panoptes/images/drift_align/20191209T182906/pole_cam01.fits
Output on /var/panoptes/images/drift_align/20191209T182906/pole_cam01.fits: Reading input file 1 of 1: "/var/panoptes/images/drift_align/20191209T182906/pole_cam01.fits"...
Extracting sources...
Downsampling by 4...
simplexy: found 422 sources.
Solving...
Reading file "/var/panoptes/images/drift_align/20191209T182906/pole_cam01.axy"...
Field 1 did not solve (index index-4118.fits, field objects 1-10).
Field 1 did not solve (index index-4117.fits, field objects 1-10).
Field 1 did not solve (index index-4116.fits, field objects 1-10).
Field 1 did not solve (index index-4115.fits, field objects 1-10).
Field 1 did not solve (index index-4114.fits, field objects 1-10).
Field 1 did not solve (index index-4113.fits, field objects 1-10).
Field 1 did not solve (index index-4112.fits, field objects 1-10).
Field 1 did not solve (index index-4111.fits, field objects 1-10).
Field 1 did not solve (index index-4110.fits, field objects 1-10).
Field 1 did not solve (index index-4118.fits, field objects 11-20).
Field 1 did not solve (index index-4117.fits, field objects 11-20).
Field 1 did not solve (index index-4116.fits, field objects 11-20).
Field 1 did not solve (index index-4115.fits, field objects 11-20).
Field 1 did not solve (index index-4114.fits, field objects 11-20).
Field 1 did not solve (index index-4113.fits, field objects 11-20).
Total CPU time limit reached!
Field 1 did not solve (index index-4112.fits, field objects 11-20).
Field: /var/panoptes/images/drift_align/20191209T182906/pole_cam01.fits
Warning: there was already a WCS file, and its timestamp has not changed.

Errors on /var/panoptes/images/drift_align/20191209T182906/pole_cam01.fits: solve-field.c:564:after_solved Failed to read WCS header from file /tmp/tmp.wcs.aTk1vu
 sip_qfits.c:267:read_header_file Failed to read FITS header from file "/tmp/tmp.wcs.aTk1vu" extension 0
 qfits:errfunc error: Failed to read FITS file "/tmp/tmp.wcs.aTk1vu"

Unable to solve pole image: Timeout('Timeout while solving: \'Reading input file 1 of 1: "/var/panoptes/images/drift_align/20191209T182906/pole_cam01.fits"...\\nExtracting sources...\\nDownsampling by 4...\\nsimplexy: found 422 sources.\\nSolving...\\nReading file "/var/panoptes/images/drift_align/20191209T182906/pole_cam01.axy"...\\nField 1 did not solve (index index-4118.fits, field objects 1-10).\\nField 1 did not solve (index index-4117.fits, field objects 1-10).\\nField 1 did not solve (index index-4116.fits, field objects 1-10).\\nField 1 did not solve (index index-4115.fits, field objects 1-10).\\nField 1 did not solve (index index-4114.fits, field objects 1-10).\\nField 1 did not solve (index index-4113.fits, field objects 1-10).\\nField 1 did not solve (index index-4112.fits, field objects 1-10).\\nField 1 did not solve (index index-4111.fits, field objects 1-10).\\nField 1 did not solve (index index-4110.fits, field objects 1-10).\\nField 1 did not solve (index index-4118.fits, field objects 11-20).\\nField 1 did not solve (index index-4117.fits, field objects 11-20).\\nField 1 did not solve (index index-4116.fits, field objects 11-20).\\nField 1 did not solve (index index-4115.fits, field objects 11-20).\\nField 1 did not solve (index index-4114.fits, field objects 11-20).\\nField 1 did not solve (index index-4113.fits, field objects 11-20).\\nTotal CPU time limit reached!\\nField 1 did not solve (index index-4112.fits, field objects 11-20).\\nField: /var/panoptes/images/drift_align/20191209T182906/pole_cam01.fits\\nWarning: there was already a WCS file, and its timestamp has not changed.\\n\' \'solve-field.c:564:after_solved Failed to read WCS header from file /tmp/tmp.wcs.aTk1vu\\n sip_qfits.c:267:read_header_file Failed to read FITS header from file "/tmp/tmp.wcs.aTk1vu" extension 0\\n qfits:errfunc error: Failed to read FITS file "/tmp/tmp.wcs.aTk1vu"\\n\'')
Will proceeed with rotation image but analysis not possible
Starting analysis of rotation image
nable to process rotation image: index -1 is out of bounds for axis 0 with size 0
Done with polar alignment test

@tmcook is this what happens when PAN012 can’t plate solve images? @wtgee is there a way to test if the jupyter-console or pocs-shell can plate solve an image? (I would like to try that first before moving our unit outside)

We could be doing an outdoor test very soon!

We have done two outdoor observation attempts since our last post. In our first attempt, bad light pollution and cloud cover kept us from finding Polaris and polar aligning. We took some test images of a bright star, Sirius, just by manually moving the mount.

During our second attempt we had much better visibility, and we were able to polar align. We attempted to observe the transit of HAT-P-30 b, but the POCS shell would not allow us to run an observation because the planet passes the meridian during observation, requiring the mount to do a meridian flip. As astronomy new comers we did not know what a meridian flip was a the time, and we still don’t know if there is a way for POCS to do the flip, and if the time lost doing the flip makes the data less usable.

During testing we ran into a few problems/questions:

  1. How does POCS track targets? Does it need feedback from plate solving to be effective?
  2. What transit depth can be detected by the unit? We know how to figure out which stars we can see from @jmk1729’s post, but are struggling to find easily detectable transits with bright enough stars.
  3. We are still playing around with camera settings and have been struggling to get images where multiple stars are visible. If someone from a light polluted city could share their camera settings it would be very helpful since I am thinking of spending a night just playing around with the camera settings.
  4. Is there a way to tell in advance if a transit will be within the constraints POCS looks for? Our last observation attempt was stopped because of this.

Hi Zach- I also ran into the meridian flip issue last summer, when PAN012 was observing known transits nightly. In case this helps with some of your questions about observing:

POCS vetoes targets that are going to cross the meridian during the minimum observing window (which by default I think is 60x 120s exposures long) because after the mount flips, all the stars you’re photographing will potentially end up on completely different parts of the camera detector. From what I understand this isn’t ideal if you’re going to try to make transit light curves later, because the data before and after the flip should be treated as 2 different observations and will have to be processed separately.

If you can, try to pick targets that either keep rising, or keep decreasing in elevation for as long as you plan to observe, to avoid the need for a flip. If you’re using the Swarthmore site, one of the columns lets you check the object’s elevation throughout the transit. When I was picking the targets for PAN012, I prioritized this right after % of transit visible, star brightness, and transit depth.

Otherwise (ie. if one night the only good target crosses the meridian :sob:) you can sort of work around POCS vetoing the target by shortening the min. observing window: in the scheduler file, set min_nexp and exp_set_size to be small (ie. 1) for the target. (Note: I’ve been able to get PAN012 take hours of data on a target that way, although sometimes it’s been prone to mount tracking errors. The scheduler also re-runs after every pic, so it wastes time. Something to be wary of)

Btw, when deciding on targets, it might be handy to try plotting each in an astronomy app to see its motion and position through the transit (and other stuff like how far it is from the moon). The following two plots are examples made using iObserve (web, macOS), but you can probably do something similar in Stellarium, etc.

Example of target needing meridian flip:

vs. a more ideal target (only on one side of sky while observing):

Hi @zacharyt (and thanks @tmcook for answers!)

Check the f-stop setting on your camera and make sure you are opened up all the way to 1.4 or not enough light will be coming through.

In general I would say don’t stress out too much about getting a transit until you just have the unit working by letting it do it’s own thing, at least for one night. Once you get the system working in that way you can then start to go after actual transit events.

Hello. I am new to the PAN015 team and will be taking over the project next year. I am currently learning about the controls and systems, including this website, so that I’ll be ready to keep our unit running. I’m excited to be involved with Project PANOPTES.

1 Like