SPHERES 63 RD ISS Test Session February 9, 2015 Abstract Test Session 63 (VERTIGO Science 3A) was performed on July 25 th, 2014. The test session used three SPHERES satellites. Software was successfully installed to facilitate automatic connection to the ISS payload network. Communication between two avionics stacks was successfully accomplished over the wireless network using ping commands as well as transferring images. A dataset for future collaborative mapping work was acquired from two inspector satellites partially circumnavigating a spinning target satellite. Due to delays during the test session, the data was not downloaded at the end of the test session, and was downloaded in a separate, dedicated test session (Test Session 73) on December 17 th, 2014. Contents 1 Test Session Objectives 2 Timeline Summary 3 Operations 3.1 Consumables Consumption 4 Results Analysis 4.1 Program 3416 63 (3 Sat) VERTIGO Science 3A: Wi-Fi Checkout and Collaborative Data Acquisition 4.1.1 P3416 Scripts 4.1.2 P3416, Test 1: Quick Checkout LED ON 4.1.3 P3416, Test 2: Goggles-to-Goggles Wireless Checkout 4.1.4 P3416: Test 4 Collaborative DAQ - Opposite Blobtrack 4.1.5 P3416: Test 5 Collaborative DAQ - Overlapping - Circumnav Int 5 Conclusions 6 Lessons Learned 7 Future Actions 8 SPHERES Team 9 Revision History 1/15 February 9, 2015
1 Test Session Objectives Test Session 63 took place on July 25 th, 2014. The first objective was to install software to facilitate wireless communications between two avionics stacks, and test the functionality of the network connection through pings and image transfers. The second objective was to acquire images of a spinning target SPHERES satellite from two separate vantage points, using two inspector satellites. To accomplish this, several scripts were used to configure the optics mounts. The objective was to automatically connect to Ethernet when available, and use wireless otherwise. Tests where one optics mount pinged the other were performed, as well as a test of image transfer between the two avionics stacks. The tests portion of the session was divided into two groups. Group A (Tests 1-5) Test 1: Quick checkout Test 2: Goggles-to-Goggles Wireless Checkout: checkout of image transfer between the two avionics stacks over WiFi Collaborative Data Acquisition Test 3: Using global metrology as a positioning method, with the target holding and then spinning about the intermediate, minor, and major axes in sequence. This test was not run. Test 4: Using blobltracking to maintain a relatively fixed position opposite the target satellite with the target holding and then spinning about the intermediate, minor, and major axes in sequence Test 5: Using blobtracking to circumnavigate a target with an overlapping field of view about with the target spinning about the intermediate axis. Group B (Tests 6-11) Variations of the same tests designed to test different spin axes. No Group B tests were run. 2 Timeline Summary Table 1 shows a summary of the tests performed and their results. Blue was the primary satellite (SN1) equipped with Goggles B; red was the secondary satellite (SN2) and was used as the target satellite; orange was the tertiary satellite (SN3) equipped with Goggles A. Table 1. Test Summary SN1 SN2 SN3 Program Test Description Start time Interval Res Res Res P3416 63 (3 Sat) VERTIGO Science 3A T1 Quick Checkout 15:54:59 0:07:05 95 1 40 T1 Quick Checkout 16:02:04 0:03:21 95 1 36 T1 Quick Checkout 16:05:25 0:03:51 95 1 48 T1 Quick Checkout 16:09:16 0:02:39 95 101 48 T2 Goggles-to-Goggles Wireless Checkout 16:11:55 0:04:55 98 7 207 T2 Goggles-to-Goggles Wireless Checkout 16:16:50 0:03:21 254 7 254 T2 Goggles-to-Goggles Wireless Checkout 16:20:11 0:16:52 255 0 255 T4 Collaborative DAQ - Opposite - Blobtrack 16:37:03 0:14:54 101 101 1 T5 Collaborative DAQ - Overlapping - Circumnav Int 16:51:57 0:02:48 255 7 255 The scripts executed as expected, and proceeded in a timely manner; however, with the need to program three SPHERES satellites and two avionics stacks, the scripts took a large amount of time to execute. The tests 2/15 February 9, 2015
experienced several difficulties with global metrology, Goggles power offs, and satellite resets. The blue satellite (SN1) was unable to properly complete quick checkout several times in a row, so an abnormally large amount of time was spent attempting to check out the satellite. The other tests were performed under the assumption that global metrology would not be available, so Test 3 was not performed. There were no fully functional collaborative data acquisition tests until the very end, so data download was not performed in this test session, but in Test Session 73 on December 17 th, 2014. Some downloaded files were corrupt, and as of the time of writing have not been properly recovered. These files are: Vertigo_Data_2014-12-17_14-39-29_GID_A_00029.sdf Vertigo_Data_2014-12-17_14-39-29_GID_A_00124.sdf Vertigo_Data_2014-12-17_14-39-29_GID_A_00172.sdf Vertigo_Data_2014-12-17_12-08-48_GID_B_00036.sdf Vertigo_Data_2014-12-17_12-08-48_GID_B_00083.sdf This means that portions of the VERTIGO data might be unexpectedly missing. After analysis of the data, is unclear what, if any, data was missing. 3 Operations There was an operational anomaly where the blue SPHERES satellite was unable to pass quick checkout, saying that no metrology was received. Later in the test, the data shows that blue recovered; however, no additional quick checkouts were performed to verify this. 3.1 Consumables Consumption Based on notes text file from SPHERES GUI. These entries may not be 100% accurate. SPHERES Batteries were changed on red (PSI02229J and PSI02233J in) at 12:45 GMT Batteries were changed on blue (PSI02262J and PSI02295J in) at 12:47 GMT Batteries were changed on red (PSI02275J and PSI02292J in) at 12:48 GMT Tank changed on orange (PSI01069J out, PSI01097J in) at 14:40 GMT Tank changed on orange (PSI01097J out, PSI01001J in) at 16:47 GMT VERTIGO The battery in Goggles B was changed around 16:34 GMT. 4 Results Analysis 4.1 Program 3416 63 (3 Sat) VERTIGO Science 3A: Wi-Fi Checkout and Collaborative Data Acquisition Each of the tests have different parameters which are described below in Table 2 and Table 3. Table 2. The parameters varied in the tests. OL and CL are open and closed loop respectively; in OL testing, position control was closed loop to mitigate drift that would otherwise be caused by airflow in the ISS; INT, MIN, and MAJ are intermediate, minor, and major axes respectively. Test Name Goggles Program Framerate [fps] Target Spin Sequence Inspectors Control 1 Quick Checkout LED ON TP_1106 5 None 3/15 February 9, 2015
2 Goggles-to-Goggles Wireless Checkout 3 Collaborative DAQ - Overlapping - Glob Met 4 Collaborative DAQ - Opposite - Blobtrack 5 Collaborative DAQ - Overlapping - Circumnav Int TP_1023 2 OL INT Global TP_1106 10 CL_HOLD, OL_INT, CL_MIN, CL_MAJ TP_1033 3 CL_HOLD, OL_INT, CL_MIN, CL_MAJ Global Blobtrack TP_1033 3 OL_INT Blobtrack Table 3. Angular velocities in each of the axes for the different spin types. Angular velocity Intermediate (INT) Minor (MIN) Major (MAJ) ω x (major) [rpm] 0.5 1 10 ω y (intermediate) [rpm] 10 1 1 ω z (minor) [rpm] 0.5 10 1 4.1.1 P3416 Scripts The following scripts were executed on both Goggles A and Goggles B: Move Data to Trash, Empty Data from Trash, Checkout & Calibration, Setup Network (Goggles A), Switch to Wireless/Ethernet, Ping Goggles A (from Goggles B), and Ping Goggles B (from Goggles A). The first set of scripts are standard scripts, run each test session to clear out old data and ensure that the cameras are calibrated appropriately; the second set of scripts were used to set up and test the wireless network between the Goggles. Goggles B was found to be well calibrated, so no action was required. Goggles A however, was out of calibration so a calibration was performed starting at 11:37:46 (Goggles A time). This calibration never completed, because the battery on Goggles A died at approximately 11:47:40 while the Goggles calibration was being computed. This means that no intrinsic or extrinsic calibration files were created or accepted, and Goggles A remained out of calibration for the remainder of the test session. The network setup scripts installed ifplugd to monitor the Ethernet cable as well as libdaemon0 (a dependency of ifplugd). When the Ethernet cable is plugged in, the eth0 route is brought up, when it is unplugged, the eth0 route is brought down. The WiFi route is always active, but the metric is higher, meaning that it defaults to eth0 when it is available. They also transferred a new interfaces file with both the eth0 and wlan0 routes, including the network SSID and password for connection to the ISS Payload network. The Setup Network (Goggles A) and Switch to Wireless/Ethernet scripts were successfully run on Goggles A; the astronauts ran both scripts five times, but running them multiple times appears to have had no negative effect. The Setup Network (Goggles B) and Switch to Wireless/Ethernet scripts were successfully run on Goggles B; here they were run only once. The network connection was then tested using pings from one Goggles to another. The first attempt did not work from Goggles A to Goggles B, but the second one did. The first attempt from Goggles B to Goggles A did work. The outputs from these scripts are shown below. The ping tests showed that the network between the two Goggles was functional. The network latency is quite high; no record of the route taken through the network was recorded. Goggles A to Goggles B VERTIGO MAINTENANCE Goggles ID: A /home/gpf_dir/scripts/ping_goggles_b.sh *** Pinging Goggles B... PING 10.11.160.84 (10.11.160.84) 56(84) bytes of data. 4/15 February 9, 2015
From 10.11.0.84 icmp_seq=1 Destination Host Unreachable From 10.11.0.84 icmp_seq=2 Destination Host Unreachable From 10.11.0.84 icmp_seq=3 Destination Host Unreachable --- 10.11.160.84 ping statistics --- 3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2007ms, pipe 3 SCRIPT NOT SUCCESSFUL VERTIGO MAINTENANCE COMPLETE VERTIGO MAINTENANCE Goggles ID: A /home/gpf_dir/scripts/ping_goggles_b.sh *** Pinging Goggles B... PING 10.11.160.84 (10.11.160.84) 56(84) bytes of data. 64 bytes from 10.11.160.84: icmp_seq=1 ttl=64 time=1005 ms 64 bytes from 10.11.160.84: icmp_seq=2 ttl=64 time=6.49 ms 64 bytes from 10.11.160.84: icmp_seq=3 ttl=64 time=5.89 ms 64 bytes from 10.11.160.84: icmp_seq=4 ttl=64 time=6.17 ms 64 bytes from 10.11.160.84: icmp_seq=5 ttl=64 time=35.8 ms --- 10.11.160.84 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4000ms rtt min/avg/max/mdev = 5.891/212.032/1005.778/397.038 ms, pipe 2 SCRIPT SUCCESSFUL VERTIGO MAINTENANCE COMPLETE Goggles B to Goggles A VERTIGO MAINTENANCE Goggles ID: B /home/gpf_dir/scripts/ping_goggles_a.sh *** Pinging Goggles A... PING 10.11.160.83 (10.11.160.83) 56(84) bytes of data. 64 bytes from 10.11.160.83: icmp_seq=1 ttl=64 time=6.76 ms 64 bytes from 10.11.160.83: icmp_seq=2 ttl=64 time=3.67 ms 64 bytes from 10.11.160.83: icmp_seq=3 ttl=64 time=3.28 ms 64 bytes from 10.11.160.83: icmp_seq=4 ttl=64 time=4.66 ms 64 bytes from 10.11.160.83: icmp_seq=5 ttl=64 time=3.12 ms --- 10.11.160.83 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4000ms rtt min/avg/max/mdev = 3.121/4.301/6.769/1.346 ms SCRIPT SUCCESSFUL VERTIGO MAINTENANCE COMPLETE 5/15 February 9, 2015
4.1.2 P3416, Test 1: Quick Checkout LED ON Four quick checkout tests were performed. In all of the quick checkouts, the red SPHERE (SN2) which did not have an attached avionics stack, passed (test result 1) and the blue sphere (SN1) failed outright, indicating no data from any beacon (test result 95). The orange sphere (SN3) which had an attached avionics stack, detected improper spacing between beacons during each run. The red and blue satellites had their positions switched for the final two quick checkouts to rule any dependence on location within the volume. It is known that the beacon file used during this test session was faulty. This was a result of an update by Bruno Alvisio by which the beacon data was made to be received directly from the SPHERES GUI instead of using a lookup table internal to SPHERES Core. This update should not have caused a problem, except for the fact that the BeaconSettings.ini contained an out of date entry. This might have contributed to orange s (SN3) improper beacon spacing return codes. Other explanations include multipath of the ultrasonic signal or the fact that the Goggles only have three ultrasonic microphones. The reason that the blue satellite (SN1) failed all metrology tests is unknown. The metrology remained nonfunctional (no data) until Test 4, where reasonable metrology signals were recorded for the first time. Goggles B, which were attached to the blue satellite, was out of batteries for all but the first quick checkout test. A review of the battery and daemon logs indicate that the GogglesDaemon was issued a shutdown command at 12:11:56 (Goggles B time). The second run of the quick checkout would have occurred at 12:14:12 (Goggles B time), but the unit remained off until 12:27:16 (Goggles B time) as indicated by the battery voltage logs. This power off went unnoticed by the crew or on the ground, and may have contributed to the problem with global metrology. The GogglesDaemon log noted the following before shutting down: Jul 25 12:11:56 PICO-19 gogglesdaemon[865]: (Daemon) System Shutdown PID 2088 Jul 25 12:11:56 PICO-19 gogglesdaemon[2088]: (Daemon) (Child Process) System Shutdown call returned 0 4.1.3 P3416, Test 2: Goggles-to-Goggles Wireless Checkout During Goggles-to-Goggles Wireless Checkout test, both satellites were supposed to take 30 images (at 2 fps) and send them to each other over the wireless network. Goggles A was supposed to be the server, sending its images first, and Goggles B was supposed to be the client, sending its images second. From the pinging scripts, it was known that establishing a connection between the two Goggles was feasible. During the first test, Goggles B was still off. As a result, the blue satellite (SN1) returned 98, a code whose origin is unknown, but has typically been associated with a malfunctioning avionics stack. Goggles A, the server, did not receive any connections from Goggles B, and as a result made the orange satellite (SN3) return 207, the code to indicate that no connection was made. Batteries were changed, and the test was re-run. In the next test, blue (SN1) still did not display any results for position, velocity or quaternion, indicating that it was still not receiving metrology despite the powered Goggles B avionics stack. The inspector satellites both returned 254, indicating a payload error with the Goggles. This occurred in Maneuver 5, as illustrated in Figure 1. Figure 1. Test results for Test 2, Run 2. 6/15 February 9, 2015
During the second run, 8 images were successfully transferred from the server to the client in 14 seconds before Goggles B shut down unexpectedly 101.3 seconds after it was turned on, at 12:29:54 (according the Goggles battery log), and the connection was lost. Again, the shutdown occurs to have been triggered by a shutdown command issued to the GogglesDaemon. Although there were other points at which the connection was checked, a disconnection at this particular moment was not accounted for in the code, and the Goggles A code crashed. After no watchdog response was received by either satellite, the payload error (254) return code was likely invoked (14 seconds of image transfer + 15 seconds of watchdog timeout gives the 29 seconds of Maneuver 4 observed in Figure 1). The end portion of the test log is shown below. The final part of the Goggles B log was truncated by the power off, but the final image OtherImage7.bmp was successfully received. Goggles A (Server) Read and sent image 0 (server) Read and sent image 1 (server) Read and sent image 2 (server) Read and sent image 3 (server) Read and sent image 4 (server) Read and sent image 5 (server) Read and sent image 6 (server) Read and sent image 7 (server) Send error (sendmessageg2g): Connection reset by peer Read and sent image 8 (server) ** END LOG ** Goggles B (Client) spheres_thread started /home/gpf_dir/results/tp_1023_wificheckout/run_ 2014_07_25_16_29_06/GSdata/OtherImage0.bmp /home/gpf_dir/results/tp_1023_wificheckout/run_ 2014_07_25_16_29_06/GSdata/OtherImage1.bmp /home/gpf_dir/results/tp_1023_wificheckout/run_ 2014_07_25_16_29_06/GSdata/OtherImage2.bmp /home/gpf_dir/results/tp_1023_wificheckout/run_ 2014_07_25_16_29_06/GSdata/OtherImage3.bmp /home/gpf_dir/results/tp_1023_wificheckout/run_ 2014_07_25_16_29_06/GSdata/OtherImage4.bmp /home/gpf_dir/results/tp_1023_wificheckout/run_ 2014_07_25_16_29_06/GSdata/OtherImage5.bmp /home/gpf_dir/results/tp_1023_wificheckout/run_ 2014_07_25_16_29_06/GSdata/OtherImage6.bmp 7/15 February 9, 2015
The second run of Test 2 proceeded almost identically to the first, including the unexpected power off of Goggles B 117.2 seconds after it was turned on (according the Goggles battery log). Once again, a faulty shutdown command was issued to GogglesDaemon. The return codes here appear to have been improperly displayed as 255, 0, 255, when really it appears from the plots as though the correct return codes were 98, 0, 98 (Figure 2); this indicates that the satellites did not reset, as implied by the 255 return code, but instead encountered a Goggles related error. Figure 2. Test results for Test 2, Run 3. The logs are very similar, however this time only 5 images were sent over approximately 13 seconds. Goggles A (Server) Read and sent image 0 (server) Read and sent image 1 (server) Read and sent image 2 (server) Read and sent image 3 (server) Read and sent image 4 (server) Send error (sendmessageg2g): Connection reset by peer Read and sent image 5 (server) ** END LOG ** Goggles B (Client) Client: received message from server of type: spheres_thread started /home/gpf_dir/results/tp_1023_wificheckout/r un_2014_07_25_16_32_08/gsdata/otherimage0.bm p Client: received message from server of type: /home/gpf_dir/results/tp_1023_wificheckout/r un_2014_07_25_16_32_08/gsdata/otherimage1.bm p Client: received message from server of type: /home/gpf_dir/results/tp_1023_wificheckout/r un_2014_07_25_16_32_08/gsdata/otherimage2.bm p Client: received message from server of type: /home/gpf_dir/results/tp_1023_wificheckout/r un_2014_07_25_16_32_08/gsdata/otherimage3.bm p Client: received message from server of type: From the two separate transfers and the Date Modified timestamps on the images, an approximate bandwidth estimate can be calculated. It should be noted that the Date Modified timestamp on the first image will indicate the 8/15 February 9, 2015
end of its transfer, so although 8 and 5 images were downloaded in each of the runs, only the times for 7 and 4 of them can be used, respectively. Each transferred image was a 1280x640 3-channel bitmap which was 1843254 bytes in size. The bandwidth estimates are shown below in Table 4. Table 4. Bandwidth estimates for image transfer Test 2 Run 2 and Run 3. T2R2 bandwidth 921627 bytes/s 7373016 bits/s T2R3 bandwidth 567155 bytes/s 4537241 bits/s Avg. bandwidth 724136 bytes/s 5793084 bits/s 4.1.4 P3416: Test 4 Collaborative DAQ - Opposite Blobtrack During this test, both Goggles A and Goggles B remained on for the entire duration of the test, and the return codes were 101, 101, 1, indicating a successful run through the entire program with some IR noise. Additionally, global metrology on the blue satellite (SN1) started functioning properly on this test. The objectives of this test were to track the target satellite with two inspector satellites, on opposite sides of the target satellite. The target satellite (SN2) was supposed to undergo a sequence of several spins. Since it was thought that the blue satellite s metrology was non-functional, the astronauts were instructed to hold the blue satellite in its initial position instead of using global metrology to go to the initial position, as was designed. Several off-nominal conditions affected this run. Firstly, thruster 0 on the red satellite was not firing at its full capability (discovered later during Test Session 66) and as a result, the target satellite s spins were not as clean as usual. The desired sequence of spins was, hold (Man. 3), intermediate axis (Man. 5), minor axis (Man. 7), and major axis (Man. 9). The metrology of these recorded spins is shown in Figure 3. The position error (target was commanded to (0, 0, 0)) indicates that the red satellite was having difficulty providing a pure torque, likely because of the malfunctioning thruster. During each spin maneuver, 30 seconds was given to spin up and the remainder was either open loop in torque (intermediate axis) or closed loop in torque (other axes). The intermediate axis spin was programmed to spin for a longer duration because of its longer periodicity. The intermediate axis spin appears to have gone quite well; indeed, this test relies mainly on the actual dynamics of the satellite. The closed loop tests (minor and major axis) do not appear to have been nearly as clean. Particularly the final (major axis) spin seems to have taken the entire allotted time just to reach its desired 10 rpm x-axis angular velocity. The reason for this is not clear since thruster 0 is not involved in an x-axis spin. 9/15 February 9, 2015
Figure 3. Position and rotation rate metrology of the target satellite (SN2) during Test 4. The Goggles LED lights were left on, despite the test plan calling for them to be off. Since the exposure time was tuned for exposure without a flash, the resulting images were slightly overexposed; this did not noticeably affect the functionality of blobtracking. The CO 2 on the orange satellite (SN3) ran out at some point during the test, and was likely low from the beginning of the test. This can most clearly be seen in the position results in Figure 4 where the position was commanded to (0, 0.68, 0) in Maneuver 2 but never made it there and then continued to drift. Unfortunately, there was a visual LOS during this time, so no instructions were given to the crew to point the orange satellite at the target. The CO 2 tank was changed immediately after this test. Figure 4. The position of the orange satellite (SN3) during Test 4. Finally, the blue satellite (SN1) was held in its proper position until blobtrack control was initialized. As this camera was properly calibrated and blue had adequate fuel, blue (SN1) was able to successfully track the spinning satellite for the entire duration of the test. An example blobtracking image from Test 4 is shown in Figure 5; here it is clear 10/15 February 9, 2015
that the combination of flash, a hardware gain of 100, and a 20 ms exposure time gave an overexposed image of the target satellite. Figure 5. A blobtracking image from the blue satellite (SN1) during Test 4. 4.1.5 P3416: Test 5 Collaborative DAQ - Overlapping - Circumnav Int Test 5 was the most successful test of the test session. In this test, both inspector satellites were supposed to point toward a central spinning satellite as it underwent an intermediate axis spin. The two inspectors were supposed to circumnavigate the target satellite using a visual-inertial blobtrack routine developed in earlier test sessions. Their field of view was supposed to overlap, with both satellites separated by an angle of approximately 60. The desired test operations are shown in Figure 6. The desired data was collected, and comprises the best collaborative data from this test session. Because of the previous experience in this test session, the astronauts were instructed to hold the blue satellite facing the target satellite until blobtracking control was established. As a result, when the inertial data is used it should be checked to understand when the astronaut was imparting external forces to the blue satellite. Figure 6. A schematic of the desired actions during Test 5. 11/15 February 9, 2015
Both satellites established a visual lock on the target and began circumnavigating. The quality of blobtracking on Goggles A was slightly diminished due to the improper calibration of the cameras, but it was successfully able to track the target satellite and circumnavigate it. Example blobtracking images captured simultaneously are shown in Figure 7. Figure 7. Blobtracking images from Goggles A (top) and Goggles B (bottom). Instead of the desired 360, the satellites only traversed approximately 90. The test appears to have been cut short by a reset of one or both of the SPHERES satellites, as the Goggles units remained on for the duration of the test and both timed out due to lack of a watchdog request. One of the last lines in both of the Goggles log files was: Watchdog expired: No data received from spheres for 10 seconds. Terminating test. The return codes (255, 7, 255) would tend to indicate that both inspectors reset and that the target reset after checking the status of its two partners. This reset is expected to have been caused by excessive IR noise from the ISS lights. Lights GLA 03A, 05A were later found to produce large amounts of IR noise (in Test Session 66), and no precautions were taken during Test Session 63 to ensure that these lights were turned off. The IR noise plots in Figure 8 show that the orange satellite was definitely experiencing excessive amounts of IR noise before the test ended 12/15 February 9, 2015
Figure 8. State of health and IR noise counts of the two inspector satellites during Test 5. An unexpected issue that arose during this test was that despite the fact that both Goggles were commanded to take images at a framerate of 3 fps, Goggles B took images at a consistently lower frame rate than Goggles A. This is shown below in Table 5 and Figure 9. The reason for this discrepancy is unknown. Table 5. Summary of the framerate discrepancy between Goggles A and Goggles B Goggles A Goggles B Total Time [ms] 172852 174237 Total Number of Images 509 418 Average Frame Rate [fps] 2.945 2.399 Figure 9. Plot of frames taken over time by Goggles A and Goggles B in Test 5. 13/15 February 9, 2015
5 Conclusions This test session successfully installed libdaemon0 and ifplugd, which automates the transition between Ethernet and WiFi so that when an Ethernet cable is plugged in it will default to an Ethernet connection, and default to a WiFi connection otherwise. Goggles-to-Goggles WiFi connectivity was verified by pinging one from the other and by transferring several images from Goggles A to Goggles B. The average bandwidth was found to be approximately 5.8 Mbps. Several problems were encountered in this test session: metrology problems with the blue satellite, frequent powering off of Goggles B; failure to recalibrate Goggles A; satellite resets due to IR; and malfunctioning thruster 0 on the red satellite. The powering off of Goggles B appears to have stemmed from shutdown commands issued to GogglesDaemon. After review of the video, it is certain that these commands did not come from the astronauts shutting the Goggles down from the GUI. The signal to shut down must have therefore come either by chance through the wireless network, or through the expansion port. As these errors were encountered three times on Goggles B and zero times on Goggles A, which would have also been subject to the same WiFi signals, it is most likely that there were erroneous shutdown commands sent over the GogglesDaemon serial communication port on the expansion port of the blue satellite. Images were obtained of a spinning target satellite from two inspector satellites circumnavigating the target. Approximately 90 of circumnavigation was completed using a blobtracking algorithm on both inspector satellites. This dataset will be useful for future work on development of collaborative mapping algorithms. The framerates were found to be slightly different for Goggles A and Goggles B for an unknown reason. 6 Lessons Learned Be clear with the astronauts about when the LED flash should be turned on and off If possible, explain the objectives to the astronauts so that they can continue the tests during LOS Print out statuses often (via stdout), including timestamps; keep in mind that the Goggles may power off at any point during the test Do not rely on the WiFi connection staying up for the entire duration of the test session; have contingencies for loss of the network connection Make sure to check frequently that all required devices are on Add a watchdog to quick checkout 7 Future Actions Port WiFi connection code to HaloCore Develop a low-bandwidth WiFi streaming method for the next VERTIGO test session 8 SPHERES Team The SPHERES team members who played a direct role in the preparation, operation, and data analysis part of Test Session TS63 are identified in Table 6. This group is in addition to the support of the SPHERES representatives at NASA. 14/15 February 9, 2015
Table 6. SPHERES Team Members for TS63. Principal Investigator Prof. David W Miller ScD 88 Lead Scientist Dr. Alvar Saenz Otero PhD 05 MIT Graduate Students Timothy Setterfield PhD Student Communications Dr. Alvar Saenz Otero PhD 05 Lead / Procedures Drew Hilton Masters Student Board / Recording / Procedures Undergraduate Students Visiting Students Marina Gràcia March Visiting Student Scribe Gabriel Urbain Visiting Student Scribe 9 Revision History Date Version Notes Released by Feb. 9, 2015 0.1 Initial draft tsetterf Feb. 18, 2015 0.2 Changed plot colors in Fig. 9. Added metrology tsetterf problems to Conclusions. Feb. 20, 2015 0.3 Added in findings about the shutdown commands found in Goggles B s DaemonLogs tsetterf 15/15 February 9, 2015