GEOFF

Journal entries imported from the previous iteration of wisrd.org

GEOFF – EXOPLANET RESEARCH

GEOFF/PANOPTES – Exoplanet Research

When a planets orbits a distant star it can pass between the star and the Earth blocking out some of the star’s light, and causing a dim in luminosity. However, other factors like atmosphere can cause similar affects. We can distinguish between these two events by looking for a pattern within the luminosity change which could be an indcator of a planet’s period. GEOFF, which was built using schematics from PANOPTES(Panoptic Astronomical Network Observatories for a Public Transiting Exoplanet Survey), automatically compiles images of the nightsky. By amassing data over extended periods of time, we are able find stars that periodically seem to dim and brighten repeatedly, and identify potential exoplanets. We hope to help aid in the verification of potential exoplanets, and possibly discover one of our own.

Goals and Objectives:

-Set up a meeting between PANOPTES members to discuss initiatives and establish explicit tasks for each group.

-Resolve remaining software issues preventing the deployment of the telescope unit. 

-Complete weatherproofing.

-Deploy the telescope unit!

PI:

Allyson Sterling, Zachary Thomas*, Ihsan A. Turk*

Members:

Ian Norfolk*, Zachary Thomas*, Jeremy Struhl*, Cole Phoenix*, Toochi Brown*, Steveen Gomez*

Note: An * designates a retired(former) group member no longer currently participating in the project.

Team A: Zachary Thomas, Allyson Sterling

Team B: Toochi Brown, Steveen Gomez, Ian Norfolk

Active group members needing a team: 

2019-10-10 Team A:

Today was a break through for the PANOPTES team. We solved a port permissions problem which has moved us substantially towards getting the software to work. We will also share our solution on the forum, as it seems others are having a port permissions problem with arduinos. Additionally, remote access was finally implemented.

We discovered this issue after accidentally unplugging our USB hub in the head unit. There was a bit of confusion, but we ended up plugging the USB hub into a different port, on the front of the NUC. When checking the connection with the lsusb command, it had a strange permission, -+, on the end of the permission chain. I looked its meaning up online, and it turns out that the + is a rarer permission used by USB hubs to grant full USB access to connected computers and devices. Because our errors in the pocs and peas shells were related to not being able to find the cameras and being unable to load the arduino environments, I went ahead and gave all permissions to all USB ports. I ran setup_pocs, and the cameras were now being detected. Sadly, setup_pocs failed later on with an AttributeError involving the initialization of the mount, and the peas_shell showed no improvement, but has a very similar error to the one now occurring in setup_pocs.

2019-10-1 Team A:

Discovered conflicts in the documentation regarding the setup of software on the PANOPTES unit. Multiple README.md files conflict with each other, Google Drive instructions, and the actual code. Currently doing more research into documentation/installation method for the unit before asking on the forum.

2019-10-1 Team A:

I have been reviewing the POCS documentation over the weekend and have found several things to fix/change. Firstly, the instructions we have did not tell us to install the PIAA repository, however our units README.md file does. I have made a backup of the panoptes folder we have been using, and am doing installs using the README.md instructions. Currently, I have installed the PIAA repository, ran install_dependencies.sh, and am running pytest now. Things are looking good so far, and for the first time our console is tagged as (panoptes-env) panoptes@pan015. 

pytest passed. Tried using the peas_shell, but upon entering the load_environment command it quit with the error BadSerialConnection. I also tried running pocs_shell and its setup_pocs command (this shouldn’t work without the peas_shell running) and got a different and non-terminating error than when run previously without peas_shell running.

After looking into the peas_shell error, I found this post on the community forum about our issue. 

https://forum.projectpanoptes.org/t/permission-problems-while-connecting-to-arduino/254

The message he describes is seen in our arduino IDE when monitored for serial data.

2019-9-16 Team A:

I fixed the pytest timezone error by changing the timezone name to ‘US/Pacific’. Also the pocs_local.yaml config file is not being used to configure the unit. It is only using pocs.yaml to configure the unit. I am altering the pocs.yaml file to give the unit the correct information, but have to discover the proper syntax because of a lack of documentation and/or knowledge.

2019-18-9 Team A:

Today I setup the units static IP, and made substantial progress on remote VNC connection. Everything for the VNC connection is setup but the program I am using, VNC viewer, is only displaying a gray screen.

2019-9-11 Team A:

I re-ran the pytest command from the POCS directory since last class I did not have the time to document its output. I immediately got a Fail, denoted “F”, from the test_arduino_io.py script, which I don’t recall happening last time. I plan to run the test again with the arduino script and serial monitor open, since those were the conditions I ran the test with last time. Also, a suspicious amount of the test_camera.py script was skipped. There was also the same error that occurred previously in test_state_machine. The pytest concluded by a script called protocol_arduinosimulator.py spamming debug messages, and at the end it appears that it is looking for an arduino script called “telemetryboard”, which is an old script of the version we have. We have the new prototype which does not have a telemetry board. It also says that its version is from 2017-09-23, so we may still have an outdated unit.

I than re-ran pytest after opening the arduino software which resolved the first failure, and changing the timezone of our unit from US/California to US/Western. This did not fix the error in test_state_machine. This might have to do with the setup_pocs command telling us to update our time.

2019-9-10 Team A:

Today I ran the pytest command from the POCS directory.  However there was an error which I will look into when I have ore time.

2019-9-3 Team B:

Tried to run the same “python3 $POCS/bin/pocs_shell” and “setup_pocs command”, which produced the same issue as before. I then began to use gphoto commands to figure out information pertaining to the cameras themselves.  Below is an image of the processes that were prompted.

2019-8-29 Team A:

Followed Wilfred’s advice from the forum to update our software. I ran the command and it altered some files but did not fix the issue. I restarted the unit and ubuntu’s “Software Updater” prompted me to install some updates, including python libraries which I accepted. It did not download before the end of my class period, so I will be coming back at lunch to check on it.

2019-8-28 Team B:

Tried to figure out why no cameras were “available” when trying to run the pocs_setup command. After running “gphoto2 –auto-detect” it was proven, that both cameras and appeared, but they were still not available when trying to run setup. This causes the program (POCS) to quit. After some research an idea was sprouted that maybe the cameras were being used by different resources, which correlated with the command “gphoto2 –summary” to get both camera’s information not working. After killing unnecessary programs the command worked, but did not solve the “no cameras available” error when running POCS.

2019-8-27 Team A:

Replaced a fuse and turned on the unit. Successfully took images using POCS commands. We will now focus on initializing POCS, getting the mount working, and then running some alignment tests. FYI: when the left camera turns on it says “cleaning sensor” and doesn’t go to the normal display. This didn’t seem to matter since the camera is still functional but we should look into it. I recorded all the commands I entered into in the terminal logs folder as a textfile called gphoto2andpocssetup.

2019-8-26 Team A:

Today I successfully took the first image using gphoto commands. We can communicate between the NUC and cameras and can mount the cameras in the head unit box and mount the box to the telescope mount. Then we will figure out how to download exposures using the panoptes software. To do this, I will try creating an images folder which is currently missing. There is a new terminal log on the NUC documenting the commands I have entered.

2019-8-23 Team B:

After trying to figure out why the camera was shutting off randomly I think we have finally found a solution. After comparing both cameras’ settings it appeared that though the camera’s auto power off was disabled, it also had a second setting ” LCD On or off” that has now been disabled. This seems to fix the issue, and now the camera does not turn off. Next step is to continue with indoor testing.

2019-8-22 Team A:

I successfully turned on the unit today, although with a few challenges. On boot, the computer gave an error about a thermal trip detected in the CPU. Everything seemed to continue functioning, and I booted the Unbuntu OS from a list the computer prompted me with. However, I smelled the camera board burning a little, so I turned off the power to the unit and investigated. I found a short by the camera’s power terminal barrel jack adapters and fixed it. On reboot, this fixed the thermal trip with the computer. This means that the units fuse on the power supply does not protect us form all shorts. This did not fix our previous camera issue, however the camera now takes longer to turn off.

I am testing to see if the issue is with the camera or the board. I am switching the ports the barrel jack adapters go into to do this. On the first attempt, the left camera failed. After switching the barrel jack adapters the same camera failed. The issue is with the left camera, from the perspective of the telescope. 

2019-8-21 Team A:

Temporarily, we are changing our goal to checking that cable connections are made correctly and that we have all the parts for the unit since our stuff was moved around a bit for cleaning staff over the summer. 

Update: I have confirmed that all of the connections are the way we left them and have taken our telescope mount out of storage and hooked it up. The only connections that aren’t the way they should be are temporarily being used for debugging of the camera/freeing up sufficient USB ports for the keyboard and mouse. Our power supply is underneath the table the unit is on.

2019-8-19 Team A: 

This year, I(Zach) am officially the principal investigator of GEOFF.  We will pick off where we left off troubleshooting a camera issue, where the right camera in the head unit turns off 15-30 seconds after the unit is turned on.  Unfortunately, I do not remember if the issue is being caused by the head unit circuit board or the camera itself. We have some data from the circuit board stored on the WISRD server, so we can look at that to help determine what is going on. Since we are very spread out over class periods we need to be sure to document everything to be efficient. Once we have successfully troubleshot the camera issue and fixed it we will continue with the final software setup by running the setup_pocs.sh script according to the instructions.

2019-8-19: The start of a new school year with different class rosters has created the need for new teams to be made based on class period. Any posts with team labels prior to 2019-5-8 refer to the following team rosters:

Team A: Zachary Thomas, Ian Norfolk

Team B: Toochi Brown, Steveen Gomez

2019-5-8 Team B:

All tests have been completed. The NUC, fan, Mount, and Camera board are all functioning properly. 

2019-4-29 Team B:

Mounted new USB hub to the camera box and are continuing to desolder one of the pins before attempting to remount the barrel jack adapter port.

2019-4-25 Team A:

Setup solder station in main WISRD area and detached control board from the cable attached to the control box. Attempted to remove solder stuck in holes of CON5. Once it was cleared, we attempted to solder a new connecter in but were unable to find one that fit.

2019-4-24 Team A:

Proofread and made minor edits to the poster for the poster presentation on Monday April 29th. Pending edits by other team members, it is ready for printing.

2019-4-18 Team A:

Found a replacement for the USB hub and suggested it to Joe via email.

2019-4-18 Team B:

Checked all cabling/connections and turned on the unit for the first time. We were successful, however the USB hub in the camera box began smoking. Upon investigation, our USB hub uses 5v, not 12v as the instructions state. We will have to order a new USB, since I am pretty sure that the 5v is fried(it literally had smoke coming out of the ports).

2019-4-17 Team A:

Created inventory spreadsheet in root GEOFF folder on server.

2019-4-15 Team A:

Verified RS232 cable connections and printed a clean copy that is now posted on the board with the connector pairs for all 9 holes.

2019-3-20 Zach at Internship:

Made a copy of pocs.yaml, renamed it to pocs_local.yaml and entered as much information as I could. I left the panid blank, as I am not sure if we are officially PAN015, if so please update the file. It looks like before we go further with the NUC setup we have to power the mount, cameras, and boards.

Because of this, we should try to attach all of the individual electronic components and get things running. I spent the rest of my time working on the camera box. I only managed to put the USB cables and power supply cables into the camera since I had to take apart the mounting plates blocking the power port, and then reassemble them. 

2019-3-20 TeamA

Upon reviewing the errors from pytest, I found that astrometry may not have properly been installed as the first error asked for it to be installed. I decided to reinstall the panoptes folder again, and this time manually place the downloaded astrometry file in the temp folder so that the install script could use it and install it the way it was intended. After the install script overwrote the astrometry file I placed, I quickly overwrote it with the original one, and this seemed to allow the install to succeed. Upon reflection, an easier way to do this would be to manually change the download to the GitHub version in the install-dependencies.sh file.

The pytest command now has no failures. A note: future revisions of the panoptes software should use the GitHub download link instead of the astrometry.net one, and the GitHub is the one that works.

2019-3-20 TeamB

Today we successfully fixed the astrometry error. I did this by downloading astrometry manually, which created a new setup.py file and others that were not present when the install was done by the terminal. The dependencies script was completed successfully and gave us instructions that walked us through the rest of the install process. It then told us to run the pytest script, and we experienced 6 errors. 

2 errors occurred in test_images.py, 4 in test_fits_utils.py, and we can’t see where the other one occurred. We will try to fix these errors and also ask the community forum if we need help.

2019-3-18 – Team A

Attempted to reinstall Panoptes software by renaming previous folder as panoptes-old and making a new one. Install progress was smooth up until the download for astrometry which was very slow at around 3 kb/s. The download and install of the “${POCS}/scripts/install/install-dependencies.sh” was still in progress when our work time ran out. I found if the download for astrometry is interrupted then the above command is restarted, instead of continuing the download it attempts to install the incomplete file left over from the interrupted attempt. This could explain the version mismatch we were getting before. I think we should allow the download to go through to completion and make sure the file is completely installed.

2019-3-18 – Team B

Added more standoffs to the boxes. We’ve recently discovered that Ubuntu cannot handle when files with the same names are in the same directory.

We fixed the error team A encountered by copying and pasting the setuptools library to the POCS directory.  Got a new error from a different part of setup.py, which also referenced its inability to import a library, this time configparser. Configparser is a series of scripts, and we could not get it to work. There was always a syntax error no matter which scripts we used. We even tried a combination of the confiparser.py script and its cache script, which didn’t work.

I think that all libraries have been installed in the wrong places. To try and fix this I copied the entire miniconda library to the POCS directory. Sadly, this did not work since the scripts are in sub directories of miniconda. We also can’t just paste all the files in miniconda directly into POCS since Ubuntu cant handle files with the same name and same directory path, and we cant change the name since some of the python scripts use script names to communicate between one another. 

We need to figure out how to make python search all subdirectories for scripts or have Ubuntu be okay with files with the same name.

2019-3-14 – Team A

Solved the below error by manually installing pip as it was missing when the install-dependencies.sh script was ran.

I then completed the command “pip install -r ${PAWS}/requirements.txt.”

Running “python ${POCS}/setup.py install” gave an error. Setting the default python version to 3 changed the error, but did not make any new progress.

One additional thing to note: after running install-dependencies.sh an error states that the version after installing astrometry is mismatched. This error occurred before the disk reset, though it may be related to the other problems we are having.

2019-3-13 – Team B

I have looked into the error and discovered two possible causes. Both involve the misreading of subdirectories. 

I began testing the error by entering the failed command in the terminal in different directories. In the directories root and “/var/panoptes” the same error occurred:

python: can’t open file ‘setup.py’: [Errno 2] No such file or directory

I thought this was strange and checked for the file setup.py in file manager, and it existed in a subdirectory of /var/panoptes, called POCS. I went to this directory, entered the command that through the error and got this back:

Traceback (most recent call last):

File “setup.py”, line 4, in <module> from setuptools import setup, find_packages

ImportError: No module named setuptools

This is important because it through not only a different error but an error that indicated it attempted to run the file. The bad news is that the setuptools library has been imported, but it is in a different subdirectory of /var/panoptes. This would lead me to believe that the new version of Ubuntu we installed(18.04.02) does not execute a command through all of its subdirectories. This is also supported by the way setup.py works. There is one host setup.py file that parses all of the information that other client files(also named setup.py) send it from other subdirectories. This means that the error is happen because either/both the library necessary for setup.py and/or its client scripts are in different subdirectories and Ubuntu will not read all of them.

The second issue: setup.py appears to not use symbolic links. These are used to switch between directories, and could explain why some subdirectories are not being read. I’m not sure about this as the command I used to find symbolic links spammed the console to the point where all of the results weren’t displayed, and the search function was glitchy because of that scale.

2019-3-11 – Team B

Started install process for PANOPTES software using the terminal. Added the environment variable code to the .profile file. While running the install-dependencies.sh script the following error occurred:

Command “python setup.py egg_info” failed with error code 1 in /tmp/pip-install-e8n_jsr_/astroscrappy/

Stopping the install process and saving the terminal code to the 2019-3-11 terminal log and then investigating the error.

2019-3-7 – Team A

Installed Ubuntu 18.04.2 LTS onto a bootable USB drive. Set USB drive to be first on NUC boot order, went through install process following prompts. The following are options that differed from default:

On updates and software, under other options, checked the option to install third party software. On installation type, selected option to “Erase disk and install Ubuntu,” as per the comment on the PANOPTES NUC instruction sheet. User, computer name, and password are the same as the previous install.

Once setup, the first thing I did was setup a secondary backup user, named WISRD, and installed updates. I then began the process of installing Chrome Remote Access.

I first installed Google Chrome. I then followed the instructions provided by Google found here. After following their instructions exactly, I followed this instruction set for making remote desktop access the desktop displayed on the monitor and not create a new session. During this process, I installed the editor “gedit” which makes editing files from the terminal easier. Remote access was tested and working at the end off this class session.

Additionally, a folder in documents called “Terminal Logs” contains the logs from all terminal usage. It is dated, divided by team, and the name of the text file describes what that terminal session was for. Please make sure to keep with the format of saving terminal logs and remember to do it.

2019-3-7 – Team B

Connected wires with a jack-header in order to power the mount.

2019-2-27

Chrome Remote Access has now successfully been installed onto the PANOPTES computer and is functioning normally!

During the process of setting up remote access we ran into trouble when the program wouldn’t allow us to enable the computer to be accessed. This was fixed by manually installing the Google Chrome browser instead of using the Chromium browser included with Ubuntu. After remote access began working, we also discovered that the program would open a new session to be accessed, which wouldn’t work when a current session was running on the monitor plugged into the NUC. Special steps were taken to make remote access use the current desktop session instead of attempting to create a new one. While these steps will hopefully only need to be used once, they have been bookmarked in case they are needed again and can be found here.

2019-2-27

Trying to troubleshoot the Chrome Remote Access onto the PANOPTES computer, but experiencing some difficulties. The Chrome Remote Desktop will not recognize that the installer needed has already been run and is impeding progression. It may be worth while looking into getting Chrome onto the PANOPTES computer.

2019-2-13

Today the control box board was completed. Now we are going to create the power supply and assemble the final unit.

Camera Box:

Control Box Board:

2019-1-30

Today the camera board was completed and all tests were passed. We are continuing by soldering the control board(aka power board).

2019-1-28

We have continued working on the Camera Board and have made lots of progress since our last update. We are currently on step 9 of 12. More importantly, the control box board(also referred to as the power board) has had its instructions updated. We will complete the camera box board(aka head unit box) before starting work on the control box board.

2019-1-17

We have learned that the control box board’s instructions are not updated. This means that we are going to switch from working on the control board to the camera box board. Currently, we are checking the PCB’s connection before continuing with soldering.

2019-1-14

Since last time we have continued on our soldering work. We thought it would be appropriate due to our lack of photos to show you some media involving the soldering process

.

PCB so far.

Jeremy working.

2019-1-9

Today both groups have begun that soldering process and we have currently soldered some parts to the PCB. We have moved the work station from the Makerspace to the side room.

2019-1-7

In contrary to what we said earlier it appears the institution has decided that we work in a single group focusing on the computer box. Every day we will check into the project sheet making sure that we know what is to be and has been worked on.

2019-1-7

Despite missing parts, we can begin assembling the electronics. Because our team is split between two class periods we will be dividing the work among the two class periods. Team one(Ihsan, Jeremy, and Ian), will work on the camera box electronics, and team two(Toochi, Zachary, Steveen, and Cole) will work on the control box electronics.

Main objectives to achieve by Monday of next week:

-Order all missing PCB components

-Each team complete two component tests

2018-12-13

Here are the components we are missing:

1x DHT22 Temperature and Humidity Sensor
1x DC/DC Voltage Regulator, 5V 1A
1x DC/DC Voltage Regulator, 9V 1A
2x 10µF ±10% 50V Ceramic Capacitor X7S Radial
2x 33µH Unshielded Wirewound Inductor 1.9A 220 mOhm Max Axial
2x 22µF ±20% 16V Ceramic Capacitor X7R Radial
1x TVS Zener Diode 12V 17.1V 1.5KE
1x Green 527nm LED Indication – Discrete 3.4V Radial
6x 2 (1 x 2) Position Shunt Connector Black Open Top 0.100″ (2.54mm) Gold
1x 3 DS18B20 Temperature Sensors

2018-11-26

Today, Joe Wise is driving to Caltech to pick up the interface circuit board. Meaning that work will soon start on soldering and electronic assembly.

2018-11-8

Today we are finalizing white papers for publication. We have received new electronics instructions from Nem, a builder of the CalTech PANOPTES Unit and major contributor to the project as a whole. We are the first unit to utilize these instructions and will be providing feed back via google docs and finding solutions to any problems that arise. These instructions feature an improved design of the PANOPTES electrical system, with two prototype circuit boards that replace three in the previous design. And it does all of this at a lower price than the original build.

2018-10-15

Ihsan, Jeremy, and Ian finished waterproofing the tripod.

2018-09-27

Jeremy and Ihsan created new cardboard models for the weatherproofing, since the original ones were lacking coverage in some areas, and did not allow full mobility of the mount.

2018-09-20

White papers:
1. Exoplanet history
2. Discovery methods
3. Transit method
4. Orbital period
5. Goldilocks zone
6. Who are the main exoplanet researchers?
7. TESS
8. History/collaborators of PANOPTES

2018-09-06

ToDo:
0. Get 3’x1’x.01″ thick aluminum sheet
0.5 Get big plastic tubing for swivel region protection
0.75 Get NUC
1. Waterproof everything
2. Edit Poster
3. Preliminary write-ups for PANOPTES paper.

2018-09-06

The following picture are the measurements for the telescope mount. They will be used to create a permanent pier for the camera box and mount.

2018-08-30

Completed hardware assembly, only electronics need configuration.