The point grey camera drivers do some sort of optimization procedure for white balancing, the settings can be very dynamic and not settle for a while.

Sometimes, the algorithm fails to set reasonable settings when there is not enough variety of color in view.

We need to figure out how to set the cameras up to start the adjusting process from settings we know are reasonable in the water.

Make the alarm handler for the kill alarm log the time and reason for any kills to a file.

• Take less than 5 mins to set up a gazebo test case
• Take less than 30 secs and 10 brain-cells (no cocaine) to start running an already existing test case

• Deal with tf desynchronization
• Trivial if we get internet on sub

Are the manufacturing differences in each new thruster enough to affect the magnetometer calibration?

Controller testing is cumbersome with cameras and GUI running.

Esp with Jason in CA, having no access to AWS or MIL-JOHNNY5

When launching the sub via sub8.launch or the sim via duck.launch, the nodes follow _orange_pipes.py and buoy_3d.py consistently crash. These are the error messages:

follow _orange_pipes.py

Exception in thread Thread-19:
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
self.run()
File "/opt/ros/indigo/lib/python2.7/dist-packages/rospy/timer.py", line 223, in run
self._callback(TimerEvent(last_expected, last_real, current_expected, current_real, last_duration))
File "/home/santiago/sub_ws/src/Sub8/gnc/sub8_perception/nodes/follow_orange_pipes.py", line 41, in publish_target_info
markers = self.find_pipe_new(np.copy(self.last_image))
File "/home/santiago/sub_ws/src/Sub8/gnc/sub8_perception/nodes/follow_orange_pipes.py", line 122, in find_pipe_new
xy_position, height = self.occ_grid.get_tf(timestamp=last_image_timestamp)
File "/home/santiago/sub_ws/src/Sub8/gnc/sub8_perception/sub8_vision_tools/marker_occ_grid.py", line 295, in get_tf
self.tf_listener.waitForTransform("/ground", "/downward", timestamp, rospy.Duration(1.0))
Exception: Lookup would require extrapolation into the past. Requested time 1.301000000 but the earliest data is at time 2.038000000, when looking up transform from frame [downward] to frame [ground]. canTransform returned after 1.00755 timeout was 1.

buoy_2d.py

OpenCV Error: Unspecified error (The boosted tree ensemble has not been trained yet) in predict, file /build/buildd/opencv-2.4.8+dfsg1/modules/ml/src/boost.cpp, line 1614
Exception in thread Thread-28:
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
self.run()
File "/opt/ros/indigo/lib/python2.7/dist-packages/rospy/timer.py", line 223, in run
self._callback(TimerEvent(last_expected, last_real, current_expected, current_real, last_duration))
File "/home/santiago/sub_ws/src/Sub8/gnc/sub8_perception/nodes/buoy_2d.py", line 136, in publish_target_info
self.find_buoys(np.copy(self.last_image))
File "/home/santiago/sub_ws/src/Sub8/gnc/sub8_perception/nodes/buoy_2d.py", line 238, in find_buoys
result = self.find_single_buoy(img, buoy_name)
File "/home/santiago/sub_ws/src/Sub8/gnc/sub8_perception/nodes/buoy_2d.py", line 193, in find_single_buoy
prediction2 = [int(x) for x in [self.boost.predict(obs) for obs in some_observations]]
error: /build/buildd/opencv-2.4.8+dfsg1/modules/ml/src/boost.cpp:1614: error: (-2) The boosted tree ensemble has not been trained yet in function predict

@mattlangford, @jpanikulam you guys might have some insight into these, I see the first one is tf related.

We've noticed this behavior when pool testing and believe it's playing a part in unstable sub behavior. Below are some notes regarding it:
@jpanikulam - Mentioned that typical behavior has the sub running this node with ~15% usage

The setup that I am using to debug this is the following:

• Running fake_imu tool in the odom_estimator package under raw_gps
• rosrun tf static_transform_publisher 0 0 0.5 0 0 0 /map /base_link 10 (Random, needed to link tf trees together)
• rosrun tf static_transform_publisher 0 0 1 0 0 0 /base_link /imu 10

With this setup, the odom_estimator is in fact railing the CPU core

• Add an indication of which thrusters are not detected.
• Check lsusb to detect if the cameras are plugged in vs the cameras launch not running.
• Detect peripheral devices like the actuator box and the passive sonar (if they respond to a RS485 ping).
• Check fps for all camera topics
• Checking for degenerate thruster configurations

Not just moving the launch files, but also figuring out why the cameras aren't behaving

• Running 3 cameras at once
• Why is it so slow over the network?

• Dynamics Compensation
• Hard-soft Compensation

I was updating some Semaphore configurations and noticed that the catkin_make -C ~/sub_ws run_tests` command generated several failures. This problem appears to date back to March (that's as far back as I went) and the command is reported as successful on Semaphore despite them. Here is an example:

[  FAILED  ] Sub8StateValidityCheckerTest.testIsValid (0 ms)
[ RUN      ] Sub8StateValidityCheckerTest.testClearance
/home/runner/sub_ws/src/Sub8/gnc/sub8_trajectory_generator/test/sub8_state_validity_checker_test.cc:14: Failure
Failed
Unimplemented test
[  FAILED  ] Sub8StateValidityCheckerTest.testClearance (0 ms)
[----------] 2 tests from Sub8StateValidityCheckerTest (1 ms total)

[----------] Global test environment tear-down
[==========] 2 tests from 1 test case ran. (1 ms total)
[  PASSED  ] 0 tests.
[  FAILED  ] 2 tests, listed below:
[  FAILED  ] Sub8StateValidityCheckerTest.testIsValid
[  FAILED  ] Sub8StateValidityCheckerTest.testClearance

Hope these are not serious issues, just wanted to point them out.

We should start removing duplicate packages in the repo.

This is some of what needs to go:

• sub8_perception/*/sub8_vision_lib
• sub8_sonar
• hydrophones
• paulboard
• some of sub8_tools
• some of sub8_msgs

Be sure to reference your PR if you do any of this and/or add to this list.

It seems like right now the one thing stopping us is broken macros in manifold.h form rawgps-tools.

@forrestv any ideas for quick fixes? Or should we just mess around with fixing the macros using the updated boost version?

• Have some knowledge of where we should look and where we have already looked
• Visualize it in Rviz

Since we are moving toward development based on softwar-common, I thought it would be a good idea to move the wiki pages that apply to all projects or MIL in general over to that repository. On top of that, there were a few pages that I found that had no useful purpose and a few that need to be updated to make sense. If nobody objects, I will start executing the changes in a week. Feel free to add to, remove from, or change the list in this issue.

I do not have the access rights to delete wiki pages, so someone with access will need to do that part. Items with a * in the comment after them will need to be taken care of by someone actually working on that project, as I so not have the knowledge to update them.

Pages that serve no purpose and should be removed:

• General To Do (Mechanical) (According to the great Ken, himself)
• Goal Manager (Seems to be based on an outdated NaviGator package)
• Model Learning (This page is very sparse and seems to be targeted twoard someone who no longer works in MIL)
• Networking (No longer needed, networking pages are being updated and moved to the software-common repository)
• Sonar Box To Do (Again, according to Genghis Ken)
• Sonar Box To Do List (Old duplicate)

Pages that are outdated and will only make sense if updated:

• Implementation Plans (*Not current, should be updated before we get too far into this development cycle)
• Mission Scheduler (Maybe hide this for history? The Git project for this seems to be more up to date)
• Open Questions
• Perception Stack (*Outdated list of people working on tasks)
• Pool Days (Some of the commands need to be updated)
• Visual SLAM (*People working on tasks should be updated)

Pages that should be moved to software-common:

• Accessing Bag Files
• Aws (As a hidden page; our in-house simulation machines do the job well and are free)
• C++ Spells (Change name [sorry Jake!] and add a few lines to do the same thing in Python)
• Code Policy
• Continuous Integration (I will be expanding this to be more informative)
• Editing the Wiki (Or possibly have a copy on all Wikis?)
• Getting Started (All project readme files will link to this page)
• Git
• Glossary
• History (Unlisted of course, and add a note about the MIL Renaissance)
• Machine Learning Tools
• Manifesto
• MIL Local Network (Update to cover the network services running on vehicles)
• Onboard Utilities (This will be rolled into the SSH Into Vehicles page)
• Other Conventions
• Reading List
• Remote Access (Needs to be updated a bunch, but will be moved)
• ROS Conventions
• ROS things
• SSH into the sub (Needs significant updating)
• SSH Keys
• Unsupported OSes (This will need to be updated a bit)

• Stereo pt cloud works well with overhead sunlight
• Suffers quite a bit in the shadows
• Why? There's clear disparity in color

Experiments already conducted

• Computing disparity on Hue instead of grayscale shows promise
• SGBM on a more downsampled image

The bag called "2016-03-28-19-13-39.bag" shows this behavior, "2016-03-28-19-17-45.bag' too, but not quite as well.

Sub8/command/sub8_launch/launch/subsystems/odometry.launch needs to have its location set to Gainesville (_start_x_ecef:=738543 _start_y_ecef:=-5498316 _start_z_ecef:=3136465) for testing in Gainesville (and San Diego when in San Diego).

Otherwise, north won't correspond to true north ... not a huge loss, but something to take note of.

I'm working on refactoring Tess's blueview sonar driver from #197. Hope to move to using the C++ library, cleaning up the code, and outputting something besides an image (pointcloud??)

@DSsoto I call dibs

• Easier sharing between robots
• Easier implementation of alarm handling, instead of a sort of lanky and cumbersome service-based organization
• This requires no major changes to the alarm node

Todo:

• Trade-study continued use of the existing Unscented Kalman Filter
• Explore using a simpler filter
• Explore using a Moving-Horizon Estimator

• libviso2
• svo
• lsdslam
• anything

Upon trying to make Semaphore compatible with the new stack, I found that it only supports building on Ubuntu 14.04. Since we decided to make the full switch to Ubuntu 16.04, this is likely going to cause problems. As I see it now, there are a few options available to us:

• Keep using Ubuntu 14.04 with ROS Indigo for builds
  • There are differences between the stacks
  • They may be close enough for our purposes
  • That said, I do not recommend this
• Find another online CI platform
  • I have not done much research yet, but I plan to soon
• Roll our own
  • Namely, Jenkins looks promising
  • We wouldn't have any limits on builds per month, processing power,build threads, etc.
  • We would have more control over the build process (e.g. each build would not be pulling dependencies for 15 min.)
  • It would be much simpler to integrate this with in-house, GPU accelerated, Monte Carlo testing on Gazebo if we wanted to down the road

I'm leaving this up to the group because whichever we decide on will have a pretty significant impact on the project, so fell free to debate.

• In the short term, everyone is going to have to compile PCL from source

For the near future, we will be using a kludge that interacts with kill_handling from the alarm system.

• Gazebo needs an X server to do camera rendering
• There's some sparse info here
• Running gz3d would be nice, info here
  • Not super dupe necessary though
  • gz3d also requires Gazebo 5

• Create subscribers, VisionProxies, etc
• This way, we can easily track what is requiring each thing

All cameras are running slow. Fastest framerate for the front cameras is 14 fps and down is 7 fps. Changing the framerate to auto or above 7 fps for the down camera in flycap causes a blank image in ROS and PointGrey unexpected ethernet packet length issues.

If I set the framerate in flycap to 30 fps or auto for the down camera and then reboot the camera and check the framerate, it stays at 30 fps. However when ROS connects to the camera and then disconnects, the fps setting reverts to 7 fps. Is that being set somewhere in ROS?

Right now, if someone modifies features.py after a classifier is trained, the classifier simply won't work anymore

Thruster with NID of 1 is not detected on the first launch of the sub from reboot. Relaunching the sub makes the thruster appear, and is detected on every subsequent launch until another reboot.

Missing: stereo_image_proc

Tasks to complete

• Torpedo board detection
• Aligning to torpedo board
• Actuating torpedo board cover
• Text recognition
• Shooting torpedo

@LucasBA - You're still onboard with working on the text recognition, correct?

Subtasks that have to be completed to carry out this mission:

• Detecting start gate
• Aligning to gate