Clean up post urc2016 (Pull for issue #8) (#12)

Clean up post urc2016 (For issue #8)
- Added README files
- Removed arm code that had no function or was unused
- Removed deprecated processes that were replaced

coreRover/roverprocess/README.md

@@ -0,0 +1,40 @@
+Post URC 2016
+=============
+Some notes on the state of the rover modules:
+
+
+ArmProcess
+----------
+The controls were threwn together the hour before the competition,
+and while joystick input from the game pad seems to work, the buttons do not.
+I2C packets seem to send properly and are recieved by the Arduino on the other end.
+The arduino code for comunications is also buggy; see /embedModules/README.md for details.
+
+Camera, Drill, StorageBin Process
+---------------------------------
+All of these work the same way: Messages defined in CanServer define translation from the state dictonary to CAN packets. Communication is one-way and message names are really flexible. To see how these messagse are used, see the Teensy code in the embedded modules directories.
+
+The camera process is not implemented, but the commented code defines how the gimbals should be controlled. See the DriveProcess for information on how to handle data coming from the WebServer.
+None of these modules were tested in the field. Drill seemed to work fine in the lab before we left for Utah.
+The Teensy on the drill may be fried.
+
+DriveProcess
+------------
+Some tweaks were made before the compute module board got swapped out, but the current code works well enough to drive. Simply translates gamepad messages to RPM messages, but some (now unused) features for telemetry and Torque/Current and Duty Cycle control are partly implemented. These interface with the VESC https://github.com/vedderb/bldc with a few modifications to the types of telemetry data sent. The modifications were not significant and much more detialed custom firmware is planned for 2017.
+
+NavProcess
+----------
+Interfaces with a Piksi RTK device using a UART and the piksi library. A good example on how to interface custom libraries with the rover system. Also contains a simulator for testing, but nothing formal.
+
+Example Processes
+-----------------
+These conain the bare minimum code to create a regular process, as well as ones that are able to communicate directly with rover hardware using a semaphore (I2C) as well as through a custom server adapter (CAN/SocketCAN).
+
+CanServer, WebServer and JsonServer
+-----------------------------------
+These act as adapters between the internal state dictionary and the outside world.
+* JsonServer translates dictonaries to JSON strings and sends them to a client over a socket
+* CanServer translates dictionary keys to priorities (user-defined) and puts them on the CAN bus
+* WebServer manages a Bottle-0.13 WSGI server. See Routes.py in the gui-software repository for information on how POST commands are turned into dictionary key:value pairs
+
+All of the Servers are set up by main.py whch manages which processes' messages are diverted to which server.  All external data coming into the server is automatically placed or upated in the global state dictionary.

embedModules/README.md

@@ -0,0 +1,25 @@
+Post URC 2016
+=============
+Some notes on some of the modules:
+
+Arm
+---
+Communications is buggy. I2C packets seem to be recieved from the rover properly,
+but the values aren't translated to motor movement.
+Directly controlling the arm with the serial command prompt works fine.
+There is likely something wrong with the `parseCommand` function,
+so one may try directly changing `g_duty_cycle` in the `recieveCommand` function.
+I'm not sure this will help however, as during debugging,
+the duty cycle manager was setting the motors correctly, but the arm didn't move.
+There may be a flag somewhere that was not set/reset properly or something.
+
+Drill, StorageBin, ExampleCAN and others using Teensy CAN bus
+-----
+This is for a Teensy 3.1/3.2 using a Microchip CAN transceiver as well as the FlexCAN library (https://github.com/teachop/FlexCAN_Library). They simply are notified of all messages and send messages at the beginning and end of the main loop.
+
+These were working in the lab, but failed at competition. Likely a fried Teensy. :frowning:
+The rover network archetecture was not well suited to the high speeds required by the motors. Improvements are needed there.
+
+Science sensors
+---------------
+We never had time to really make these work. Potential benchtop code is here in the sensors folder.

embedModules/arm2016/new/arm2016_comms.h

@@ -1,3 +1,4 @@
+// BUGGY! see /embededModules/README.md for prose
 #ifndef ARM2016_COMMS
 #define ARM2016_COMMS
 
@@ -30,6 +31,9 @@ uint16_t packet::checksum() {
 }
 
 
+/* NOTE: parseCommand doesn't work correctly.
+ * Try bypassing it and setting g_duty_cycle directly for this function.
+ */
 void receiveCommand(int count) {
   byte in_bytes[count]; // buffer
   int i = 0;
@@ -112,6 +116,10 @@ void sendPosition() {
 
 
 //command parsing
+/* NOTE: This may not be behaving properly, motors do not move when told to.
+ * The duty cycle manager seems to be recieving the values correctly,
+ * and sets the motors accordingly, but they don't move.
+ */
 void parseCommand(packet command) {
 	g_ivk_controller = command.type == INVERSE_KIN_CON;
 	if(command.type == MANUAL) { // actions for manual command