SumoLessonsLearned


 * Lessons Learnt**
 * 1) The inaccuracy of the ultrasonic reading was a major concern. The robots always missed the target by some distance if they were more than 40-50 cms apart and were themselves spinning.
 * 2) As the VPL diagram grows bigger, understanding the execution cycle in a multi-threaded environment becomes quite difficult.
 * 3) VPL doesn't provide all the functionalities which seem logical (or we were unable to use them properly).


 * Things to Do**
 * 1) A Comparison of NXT-G and VPL programs needs to be done to see if there is a big difference in their performance.
 * 2) Compilation of VPL programs as C# services and running the code from Visual Studio to figure out if it improves the performance.

>>> 
 * Related Links**
 * 1) [|Infrared vs. Ultrasonic Sensors]
 * 2) [|Discussion on Motor Control - No Easy Solution]
 * Excerpts
 * there is going to be some inherent overshoot. because the controller is on the PC, there are 2 bluetooth transmissions that are required before the stop is executed. the motor can spin a lot in this time. there is not much you can do about this other than slowing down your motors.
 * My objective is to be able to move the motor from a known position to another known position by giving it the number of degrees it should move. (note that this works just fine in NXT-G)
 * 1) [|Rotate Degree Issues]
 * 2) [|Communication Over Bluetooth]
 * Excerpt
 * My personal opinion is that a program running on the brick is a better approach. This allows you to monitor the wheel encoders directly on the brick and provide more accurate control of the wheels. When you run services over Bluetooth to control the wheels using encoder values there is a significant lag due to the Bluetooth transmission delays. Consequently you will find that exact motor control is not possible.