The key to a robust development process is the use of a Simulator. Running code directly on Robot Hardware has several shortcomings that are addressed by the simulator.
| Software Simulator | Robot Hardware |
| Easy to view individual loops, making glitch/transient detection much easier. | Runs at full speed only. |
| Able to display all variables in each cycle. | Very limited visibility into variable values. |
| No danger to people or hardware. | Out of control software is a danger to people, electroncs, mechanical systems. |
| Can be tested very early in the project schedule. | Requires Robot Hardware to be built. Also requires Operator Interface to be working. And typically at least a simple playing field is required. |
| Update cycle is short, measured in seconds. [About 10 seconds on Linux. W2K is about 8 times slower.] | Update cycle is several minutes. |
The Simulator consists of standardized code, that will be used by all teams without modification, and custom code, that each team must adapt to model their robot.
Looking at it another way, the code consists of two parts: C and Tcl. The C code is mostly just the FrcCode that is developed for the Robot. But it also includes some simulator specific code to allow communication with the Tcl process. This simulator specific C code is standardized across the many teams.
The Tcl code also includes standardized code as well as custom code. To support the custom Tcl code process, a library of Robot Simulating procedures has been implemented. Many of the most common robot functions are implemented in the library.
Since all of the code is open source, teams can learn from the programming techniques used here. They can extend the Tcl library to cover robotic modules. Those modules can then be contributed back to the library. Contributions bring recognition to the contributing team. At the same time, they make the entire FIRST organization more effective.
|
|
The simulation consists of two programs which communicate via messages over Unix style pipes. (On Windoze computers the nearest equivalent to a pipe is used.) The communication is in the form of messages, which are documented below.
The controlling program is written in Tcl. This is the program that is started first. It then starts the C based program as a child process. The Tcl program consists mainly of 4 parts (altho we will see that there are other files that we edit for now).
The C based program consists of two parts.
The standard simulator software manages the communication and process control so ideally it should not impact the team debug process. But since all of this software is fairly immature, there is no guarrantee of robustness. Therefore it is useful to know the communication structure.
The two programs (Tcl based and C based) communicate via messages. In the tables below you will notice that there are a few messages that are not fully implemented. The intention is to fill that out in the future. Unimplemented messages merely cause messages to be logged in the logfile. But in the mean time, the simulator is useful for debugging robot functions that are not dependent on the few unimplemented messages.
|
Message Flag |
c implemented | tcl implemented | Comments |
| rslow | y | y | This updates the operator interface. |
| rfast | y | y | This updates the robot based hardware. |
| GetInput: | y | y | This is the 'prompt' for more input in the C program. |
|
error warning note |
y | y | These messages are provided to support the debug process. In the text object, these messages are colorized for easy reference. |
| # text | y | y | In Tcl, any unrecognized messages are simply echoed to the screen and to the logfile. Thus this 'comment' feature is supported by default. |
|
Message Name |
Message Flag |
c implemented | tcl implemented | Comments |
| MSG_TSLOW | tslow | y | y | This is a message to the C code that a a simulated radio packet has come in. Thus the C code gets new values from the Operator Interface. |
| MSG_TFAST | tfast | y | y | This is a message to the C code that we are simulating a fast cycle. The C code gets new values from the simulated Robot hardware. |
| MSG_TINTERRUPT | interrupt | y | n | |
| MSG_TREPORT | report | y | n |
The user has full control over the ratio of fast to slow cycles. This is provided on one of the panels of the Tcl program. This same panel also provides buttons to trigger interrupts and report requests. Those buttons will send the corresponding messages in the table above.
The customizing is in several steps. This documentation will walk you through each step.