Mission Possible/Lego Programming

=Introduction= Lego Mindstorms and NXT are very convenient, if expensive, ways to build a variety of robotic devices for events like [Electric Vehicle], [Robot Ramble], [Robo-Cross], [Robo-Billiards], and [Mission Possible C]. The programming language that these systems are shipped with, however, is entirely unsuited for serious competition. Third party text-based programming environments are widely availible, relatively easy to use, and are vastly more powerful than the provided systems.

NQC is an excellent programming language for Mindstorms. It will take a little while to learn, but the manual is good and the payoffs are enormous. A good programming environment can be found here while the actual NQC site can be found here. If you are using the NXT, substitue NBC or NXC for NQC, both of which can be found here

=NQC and its brethren= This section is written specifically for NQC, but the code for programming the NXT is almost identical, so it should be easily translated.

General Rules

 * You should always "SetSensorType(SENSOR_#, SENSOR_TYPE_NONE)" for touch and temperature sensors. It is also useful for light sensors if you need to disable the red LED, which can hinder readings for the presence or absence of light. If you are trying to determine the color of an object, leave the TYPE as LIGHT and if you are using a rotation sensor, leave the TYPE as ROTATION.
 * Regardless of the sensor type, use "SetSensorMode(SENSOR_#, SENSOR_MODE_RAW);". This will prevent the RCX from even thinking about using % for any of the readings, which lets you get more accurate results.

Using a datalogger program is an easy way to collect data in a format that you can then view in Excel to analyze for trends and peaks.

=Good Practices for using programmed devices=
 * Always include a copy of your code at device impound. If the judge doesn't want it, that's fine, but he might.
 * At least one person present for the running of the device should be able to fully explain the code.
 * Comment your code enough that a reader will at least get the general idea of what is going on.
 * Be especially clear in your comments whenever you use a timer or wait(variable) command if the event prohibits certain time manipulations or parallel events.
 * When you can, code the actions so that they trigger at variables that are dependent on the current environment, rather than a static number. What I mean by this is that you should try to include sections of code that let your machine adapt to the current light/sound/temperature conditions. Take a sample of the conditions and then have the transfer trigger whenever the sensor reaches "conditions + 5" or whatever is appropriate.