Is there some way to simulate a cRIO on a laptop when teaching programming?
EDIT: I love python but its not real developed enough yet, plus the school has experience with Java, so that is what we will be using.
You could program for a non-crio target.
If you are using LabVIEW, you can use indicators and sliders as your input and output. Create a new VI from scratch, drag a while loop and wait (about 25ms seems good for robots), and click the run button to simulate. If it tries to download to a robot, then you created the VI in an RT project (which you don’t want to do).
If you are using a different language, you can compile C/C++ code for consoles fairly easily, but GUI’s are fairly hard for new programmers to quickly create and GUI programming is nothing like RT programming.
Either way, you’ll be simulating the algorithm and teaching programming concepts, not the actual use of the WPI library (which is only a small part of robot programming). This is still useful even during the build season, to prove algorithms before running them.
Algorithm development is one of my favorite parts of programming, and I spend a good deal of time each season simulating the more complex portions of code on my laptop while I’m not even at the shop.
Are you looking to simulate the cRIO or a robotic environment?
Palardy’s got it right. You can just “stub” out the entire cRIO as this is “only a small part of robot programming.” I would even say VERY small part if your robot does only half the stuff the Killer Bees do.
To do this, just create one “hardware interface” subroutine/class and make a call to it every cycle through your robot code. Or stick it in another thread with a timer or however your team (and other teams who do not use LabVIEW) do it. The trick is to group all of your cRIO specific code in there… I’m not sure how the Java and C++ environments work, but you probably also have to create a surrogate Java class for the “main” process because that won’t run in the PC environment either? That should just be a matter of creating a mostly empty class with the same interface and included using a different header file with the same class name.
This kind of partition in your robot code is HIGHLY recommended. It allows you to separate your robot control algorithms from the hardware interface and VALIDATE the hardware specific portion (polarity, units, encoder functionality, low level controls, etc.) INDEPENDENTLY. If you have a simulator, you can VERIFY the algorithms as well. You should have your SW team create a HW checkout program and NEVER test code on the robot unless it passes. This saves a lot of headaches and is a useful diagnostic tool for the entire season.
Once you have the partition, you can stick any kind of robot model you want (simple or complex) inside the stub for execution on the PC. Of course I highly recommend the Team 302 trainer VIRSYS http://www.virsys.org. 
If you can write a UDP send and receive routine for floating point arrays (we already have one that’s close in C# / javascript) then you can get VIRSYS running for C++ in short order. The first (now second) release is designed as an instructional tool.
How do you plan on simulating the Joystick, other control boxes, and driver’s station? This is not the cRIO. LabVIEW makes this easy with lots of virtual dials, switches, charts, and simple recognition of joysticks (limited to first 3 axes and 16? buttons). You can add that to the tool chain as a “driver station” stub in exactly the same way (just borrow the setup and UDP communications already available in the VIRSYS LabVIEW distribution).
I don’t really know Java. However, if you are willing to give it a try, I can create a quick and dirty C++ example of this that should convert without too much difficulty.
Great question and good luck!!
Code simulator is coming for Python.
See RobotPySim on https://github.com/robotpy. Current version is very (very (very)) early and lacks documentation, but will display the output of jaguars in response to the y axis of a joystick. Replace robot.py with your own, set up how to display outputs and receive inputs in robotconfig, and run robotpysim.py. Included test robot drives three motors in response to one joystick Y axis, controlled with w and s. Requires python 3.1.X (the same as the one running on the CRIO) and the correct pygame version for that release.
There appears to be a new CRIO simulator available.
Has anyone gotten the FrcSimulatorClient-full-0.1a.jar to work?
Does anyone have documentation?
Dave Frederick, Manassas VA
I was a CSA(Control System Adviser) this year. that tool is used by the FTAs and CSAs to confirm the field functionality and troubleshooting. It only simulates a robot from the FMS comms point of view and not much else.
One could conceivably use a Proxy (http://en.wikipedia.org/wiki/Proxy_pattern) to abstract WPILib from the actual code, allowing a mock implementation with GUI/output to be set up in its place while using the same calls and method signatures. However, you’d have to make sure everything you’re using is covered by the proxy (which can be a lot of work).
I guess I’ve never thought about it – would using the same package names in a mock implementation be bad form? I suppose it’s not a big deal if released under the same license as the original. It sure would make it easier on the proxy (otherwise some configuration file would have to be set up, or the code in the proxy would have to be changed when building differently).
Read one of my first posts on this forum as linked here:
That has not been updated in quite some time and the students that wrote most of it have moved on.
Perhaps you’ll find some value in it.
I’m one of the ones working on that, it’s in the very early stages and can only really be used to verify that code you’ve written works (to some degree). We do plan to add a gui display of the robot eventually.
As the wiki on the website says, just run java --classpath FrcSimulatorClient-xx.xxx.jar:YourJarNameOrPathToClassFiles net.sourceforge.frcsimulator.Client --gui -s your.class.package.and.name
We have changed the command line arguments in the svn(dev) version after developing a class to handle them, reading the doc within the code should help alot. (once we figure out a good way to post the javadoc, we’ll do that, until then you can read the code or generate it yourself).
Looks like someone owes GoDaddy a couple of bucks. :o
Here’s the new location: http://www.multibody.org/VIRSYS/
Not exactly 
It’s the hosting I’m not paying for. For some reason I only have one free economy hosting between my two sites. I could point the site to the multibody.org domain or to team302.org, but the subsequent VIRSYS link would need to be front page stuff and this seems inappropriate given the inactive state of VIRSYS development.
On the plus side, I won a contract that starts in a few weeks and some of the scope is relevant to making progress on VIRSYS.