Hey everyone, Head Programmer Eric here. As requested by rookiefirsts, I will be sharing some of my own advice which I have learned over time about implementing and using sensors.
 
1. Design and planning
 
Make sure you’re absolutely involved in the design process so that your team knows where you put your sensors at so they can build around it and know how to incorporate it. You also want to make sure that the placement of your sensors are good. A place easy to reach, protected by possible field projectiles and from your own robot’s subsystems.
 
2. Testing hardware alone
 
After you’ve planned everything out and have gotten your hardware together, make sure you actually test it. This is a large portion of my time while the mechanical team is busy building the actual robot. With the limited time we’re given, we have to make sure that as soon as the robot is available, everything is okay and ready to go to get testing and practice underway. Try to simulate the environment that the sensor will be placed under. For example, testing an ultrasonic rangefinder at expected distances or swinging a gyro around at the rate your robot may turn at. This way, you’ll lower the amount of debugging you’ll have to do when your hardware actually gets on the robot.
 
3. Testing hardware in its mechanical environment
 
Whenever you’re able to, mount your sensors/electronics onto your mechanical subsystems and test them out. Check if the feedback is as expected or if it is behaving properly. Hopefully, everything is okay at this point but there are times when your sensors/electronics simply don’t agree with you such as producing too much noise (unwanted readings) in its mechanical environment or not being precise enough for the job. The earlier steps are there to reduce this occurrence, but when this happens, you have to think about other solutions for the job. Remember that there can be more than one way to do the same objective.
 
 
Now that’s the general outline I follow throughout the season. However, when you’re working with the actual hardware, there are many guidelines I follow to reduce the frustration while actually getting everything to work.
 
A. Know your hardware
 
Know what it does and in what form does it give it to you. Is it analog or digital? How will it interface with the microcontroller/brain of the robot? Know where you bought it from or where it came from so you can check out what the manufacturers have to say about it, such as its pinout (how to wire it), limitations and/or proper usage. You may have to do some research to find this all out. Be aware that FIRST supplies quite a bit of information about this, especially information about devices given in the Kit of Parts.
 
B. Obtaining Data from your Sensors
 
Is this device supported in your programming language? If not, can you create a way to interpret the raw data is gives? For example, there is no clear potentiometer class in the WPILib. However I know that the potentiometers my team has are analog devices, so I can read the voltage it is giving in the AnalogChannel class and based off of that, know how many rotations the potentiometer has turned.
 
C. Debugging
 
I. Make sure everything is turned on, plugged in and your robot is enabled. This may sound silly but personally, I’ve been subject to this symptom quite a number of times. I’m staring intently at the Dashboard/Driver Station tapping buttons on the controller and nothing is responding. Then I find out that the robot isn’t even turned on or I haven’t even enabled the robot.
 
II. One of the things I do when I am testing all of our devices is that I separate all the code to read the feedback from a device that I know works and document it so that in the future, if a certain device doesn’t work, I can rerun this code to further deduce any problems.
 
III. Check the wiring. Make sure all the connections are okay and that voltage is running through the correct wires. One of the ways you can do this is to take a multimeter and check that the correct amount of voltage is running through each wire. For example, in the FRC 2012 KOP, there was a gyro that was meant to be plugged into the Analog Breakout of the cRIO. 5 Volts get supplied to this gyro and when standing still, about 2.5 Volts was sent back through the signal wire.
 
IV. Pay attention to errors when running your code. You can do this with the NetConsole which should be supplied in all the tools through LabVIEW. Sometimes exception errors pop up where the logic in your code may be wrong or your hardware is incorrectly configured. This could put a stop to the rest of your code.
 
 
 
On another note, its pretty late into the season but I’ve gotten done quite a bit of my reference for programming in robotics which can be found here:
 
https://docs.google.com/document/d/1b-d60PLkSIPS35jIJ-kZYa6BKLmqso1g2bzMYbIHZ6A/edit
 
Feel free to make any comments on it. I plan on periodically updating it.
 
I’ve also recently opened up the RoboLancers’ repository on google code (which I should have done earlier in the season) which can be at here:
 
http://code.google.com/p/robolancers/
 
I plan on putting all our code here from now on, including all of our robots we make and all the code I’ve made for various devices such as the ultrasonic rangefinder in the 2012 FRC KOP.