Missed in previous commit

Author: formal

hardware/Laser-Scanner/README.md

@@ -2,7 +2,7 @@
 
 ### Directory Contents
 
-This directory contains number of simple sketches for testing the laser scanner.
+This directory contains a number of simple sketches for testing the laser scanner.
 
 #### laser_moto_test_1
 

hardware/Motors/OminTestSoftware_3/OminTestSoftware_3.ino

@@ -2,11 +2,10 @@
 // Attempt to make each encoder yield the same number of ticks over time and
 // hopefully move in a straight line.
 //
-// We reset the encoder counts every 'delayTime' milliseconds, and reset the
-// counters, but we keep a running total, i.e., we adjust speed based on the
-// counts for the last period
+// We reset the encoder counts every 'delayTime' milliseconds, but we keep a running total, 
+// i.e., we adjust speed based on the counts for the last period
 //
-// ** This does not seem to work and the total accounts diverge.
+// ** This does not seem to work and the total counts diverge.
 //
 
 int D1 = 4;   // direction

hardware/Motors/OmniTestSoftware_1/OmniTestSoftware_1.ino

@@ -1,36 +1,23 @@
-## laser scanner
+## Motors
 
 ### Directory Contents
 
-This directory contains number of simple sketches for testing the laser scanner.
+This directory contains a number of simple sketches for testing the main motors of the robot.
 
-#### laser_moto_test_1
+#### OmniTestSoftware_1
 
-This sketch checks that the DC motor & encoder are working. The function `encoderIS()` handles the encoder interrupts. There should be 3360 per revolution of the laser scanner. The sketch also contains code to drive the DC motor at different speeds.
+This sketch drives the two motors connected to one Uno and effectively moves the Robot diagonally. *Note that we keep the speed of motor `M1` fixed and vary the speed of motor `M2`*.
 
-#### laser_moto_test_2
+This sketch attempts to make each encoder yield the same number of ticks over time and hopefully move in a straight line. We reset the encoder counts every `delayTime` milliseconds, but we keep a running total, i.e., we adjust speed based on the counts for the last period
 
-This is essentially the same as `laser_moto_test_1` except that it stops after 15 revolution of the laser scanner.
+**This does not work and the total counts diverge**.
 
-#### laser-single-distance
+#### OmniTestSoftware_2
 
-This example is supplied by the manufacturer.
+This sketch is similar to `OmniTestSoftware_1`, but we adjust the motor speeds based on the total number of ticks and not just the number in each period.
 
-#### laser-continuous-distance
+**This works much better than `OmniTestSoftware_1`**.
 
-This example is supplied by the manufacturer.
+#### OmniTestSoftware_2
 
-#### laser-continuous-distance-interrupt
-
-This is a modification of `laser-continuous-distance` that uses interrupts to determine when a new reading has arrived.
-
-#### combined_test_1
-
-This is a combined test of the laser and DC motor, i.e., the head rotates and laser fires continuously. **This sketch needs more work.**
-
-### Issues
-
-1. It is essential that we handle every interrupt generated by the encoder. **How can we assure that this happens even when other code is executing? For example, does the `Serial` library interfere with interrupts, e.g., by disabling them at any stage?**
-1. Using `laser_moto_test_2` it is clear that the head does not finish in same position as it started. **Why?**
-1. The `combined_test_1` sketch does not perform very well; it behaviour is some what erratic. This probably due time issues and lost interrupts.
-1. **If the inaccuracies in the rotation the the scanner and the laser range finding are significant what can we do in software to improve accuracy? **  
+Again, this sketch is similar to `OmniTestSoftware_1`, but its main use is to check that we are using the correct encoders, i.e., if we switch one motor on, then that motor's encoder should have a non-zero count. *Note that the other motor should have a zero count and if it does not, then there is something wrong with the hardware*.