Currently the MotorController is aware of the state of the thrusters and will accelerate gently to a target speed. However, this is not the case when mixing pitch/yaw with x/y/z movement. Some thrusters will instantly jump from their old state to the new one to make the movement or to execute a turn.

When the client is connected to the beaglebone blacks and you click the "Get Ruby Output" button it immediately causes a disconnection between server and client.

I just got the information and am looking into the hydrophones.

Noticed a decrease in server performance lately - however that may have been just a result of slow packet transfer or an efficiency problem in either packet transfer or level of interpretation. Reverted to original Server w/o pwm for forensic investigation.

I have finished the generic pid controller library and tested it in isolation, but I still need to test it in the water.

We need to be able to receive data from the IMU.

• IMU Controller is initialized with a connection to the Node app.
• IMU Controller receives data from the drivers.
• Node app has interface to the IMU Controller.

The I feel like the best implementation is to have the Node interface constantly pulling for data and caching the most recent data set.

*A note on acronyms in code: The generally accepted convention for acronyms in code is to capitalize only the first letter, i.e.: ImuController vs IMUController.

Order Application 1:

• 4x BeagleBone Blacks
• 4x OV5642 1080p Cameras
• 8x Heat Sensors
• 10x Current Sensors
• 1x IMU

Various Camera Communication Circuitry and Components:
LEDs, Fiber Optics, Op-Amps, Photoresistors, Transistors, Resistors, Breadboards, Wire

Order Application 2:

• 4x TI Differential Transmitter ICs
• 4x TI Differential Receiver ICs
• 4x Water Sensors

Various Circuitry and Components:
Resistors, Capacitors

This error is given when trying to compile the server in Poseidon/Server/build.

As it turns out from another electrical engineer's light research, writing to a file on the BeagleBone to continuously toggle a GPO only yields about a 2KHz emulated clock speed - slower than the slowest baud rate in the Arduino's Serial communication.

That is:
2KHz / 5 Latency = 400B/s
400B.s / 9B.msg = 44M/s

This is still decent but for elements that need to be updated more than twice a second, this is not fast enough. The BeagleBone Black does offer two on-board PRU peripherals (Programmable Real-Time Units). Based on the same research above, it has been found that the PRU can emulate a 2 - 25MHz clock speed - faster than the Arduino it's self.

That is:
2MHz / 5 Latency = 400KB/s
400KB.s / 9B.msg = 45KM/s

So all C++ code for the 'ArduBone Protocol' must be ported over to PRU assemebly. An external program can make a call to send or receive data with the appropriate parameters.

During an attempt to read from camera registers, all read-in's returned '0'. Re-evaluating the wiring, one of the lines was found to be an open-circuit, thus the camera was never powered through any previous tests - making all observed results false-positives.

Brake mode occurs when moving from forwards to backwards. This can be prevented by writing -0.1, 0, and then the backwards velocity. The cycling undoes the break.

Likewise, the ESCs need to cycle to 30% and then 0 before they can be used.

Turn the skeletal structure of the Mark II Proto into an ROV.

Wouldn't adding an "exit" command be a good way to close the bootstrap application?

The minimum rate to turn the propellers in the left/right direction seems to be 0.29, and the minimum for Z seems to be 0.24. The software should take this into account.

Sometimes two JSON objects will be returned simultaneously in the same connection, which causes parsing issues. They should be separated and handled individually.

• Compile openCV on the bone
• Install HD camera drivers

The C++ API classes are designed to throw exceptions when something goes wrong, such as passing an invalid argument (-11) to a method, or creating a second instance of ThrustController. Ruby shows "unknown C++ exception" but doesn't show the exception text. This makes debugging Ruby-side very difficult.

Also, remove uneeded components.

We need to add a unit testing framework for the Brain. Jasmine is a solution I've used before. I don't know whether it's the best for Node integration.

Requirements:

• PiVision gets location of each pole it finds on X axis
• PiVision translates coordinates of each pole to lie on a grid with the origin at the center of PiVision's sight

ThrustController and possibly CommandDispatcher should be tested.

The current application has lost much of it's Doxygen comments. These need to be updated. In addition, we need to make sure all of the author comments at the top of files are correct.

We need a power controller to turn on the ESCs. The ESC driver should implement the IPowerModule interface and live in the Dirvers directory. The power controller should implement the IPowerController interface and live in the Peripherals directory.

• Arduino can toggle ESCs.
• Add Beaglebone driver for ESCs
• Add PowerController
• Add PowerController interface in Node app
• CommandDispatcher dispatches PowerController commmands

Though the bone's socket server had successfully implemented pwm signal processing, some ESCs require arming and other special signals for revers control.

• Objective: arm 4-6 ESCs and control forward and reverse motions with remote.
• Bonus objective: arm within 1-5 seconds

We need a way to turn on/off the lights on the sub. I kinda feel like it makes more sense for the lights to be turned on when the app is started and are left on.

• Define light interfaces
• Arduino can control lights
• Add light controller
• Add light driver
• Lights switched on during bootstrap

One tab per feature:

• Motor Control & Status
• Visuospatial 3D Map, Navigation, Basic Sensor Readings
• Hull Integrity & Detailed Sensor Readings

This should be as simple as possible. Nothing fancy or pretty. This should be just enough to be able to give directions to and get sensor data from the sub remotely.

When the sub starts searching for a gate, it needs to know what initial steps to take.

Read in HSYNC buffer from camera and write to processor. VSYNC validates a single frame. (The OV7670 camera defaults to approximately 30FPS at 32kp/frame while the OV5642 defaults to approximately 15FPS at 5mp/frame.)

Create raw YUV image file from buffers.

If the Arduino crashes or is unplugged when the application is running, this error occurs. The current solution is to reboot the machine, or in a worst case scenario, require a power-cycle.

Perhaps restarting the USB device interface will resolve the issue.

(a less common condition is when the USB hardware shuts down and the drivers are still functional)

Ensure we can communicate with the thrusters.

• Thrust Controller is initialized with a connection to the Node app.
• Thrust Controller communicates with all the correct drivers.
• Node app has an interface to communicate with the Thrust Controller.

We need to pay extra care to making the Thrust Controller real time. Queuing tasks for the drivers should be avoided.

class IThrustController {
  virtual void GoDirection(int forward, int strafe, int dive) = 0;
  virtual void FaceDirection(int yaw) = 0;
}

class IThruster {
  virtual void Thrust(int powerLevel) = 0;
}

Requrements:

• A method called in BoneCentral's brain initializes detection
• PiVision gets an image and detects at least one pole

I added PWM support to the remote server and all seems to be working fine based on LED tests. Unfortunately, initialization is still having a few problems at the moment. Aside from that, the next stage is to include said arming sequence to enable full ESC functionality.

Re-add the old I2C driver code and make sure it works with our code base.

Currently the function faceDirection doesn't take an angle as its parameter, but it takes a magnitude. In order to facilitate autonomous functions, faceDirection needs to take an angle as its parameter and be able to make the sub turn at that angle.

Attempts by Ruby to read from the IMUSensor cause Ruby to stop immediately. I suspect a segfault or similar signal.

TCP connections can sometimes get left open if the server is killed, so the port will be stuck in the TIME_WAIT state. This prevents the server from correctly listening on that port again.

When an index value outside the bounds of the controller array is passed to the Arduino, the microcontroller becomes unresponsive and requires a physical reset. Should we add a watchdog timer or just go simple and catch all bad input?