Our mechanical team got behind schedule and was finished just before the deadline. So we have a problem. Our Robot isn’t programmed and its already been shipped. Does anyone have any ideas on how I can program it without it here? Or are we totally screwed?:ahh:
Did you keep behind your cRIO and power distribution board? If you did you can work and test sections of code by rebuilding or simulating parts of your robot in the lab.
I would look for an additional DS, cRIO and the modules that you are using on the robot. Another team might have an extra. You can hook up motors to speed controllers and see which direction they are moving ( or watch the LEDs). You can also hook up whatever sensors you are using to make sure they are providing proper feedback.
The default code should be enough to at least get your robot moving.
If you have already shipped the cRIO, you can run the code on your computer (to an extent). See the following link
http://www.lvmastery.com/TipJar2009-02-08_3
How complicated is the mechanism you are trying to control? Is it just direct joystick to motor controls, or do you plan on automating certain functions of your robot?
Also, it’s pretty easy to change motor direction once you get to competition, as it’s just a True/False boolean for the Open Motor.vi
Feel free to ask me for any help.
Make some assumptions and program it as best you can.
If you need any help, our programmer and I can guide you through the process, but the most important thing is to make the code very accessible. As long as you know what assumptions you made, and then can change those assumptions quickly based on experimental measurements, the code will be good enough.
If you have odd sensors and such, make sure you read the documentation so you know where to attach them and how to have your program interface with them.
I’ve created a GUI “Test Harness” for WPILib/C++ that allows you to run bot code on your computer using a normal compiler. Many of the basic items (motors, encoders, joysticks, I/O) are either fully or partially implemented.
I’m hoping to finish up the rest of it tonight or later this week, and will be releasing it shortly after.
Remember that comments are your friend! You will have Thursday at the competition to debug, but remember your team will want to do practice rounds, etc. and any mechanical changes that need to be done (there will be mechanical problems :P). If you make a list of everything you need to test debug and correlate that to comments in your code, it should make your Thursday more efficient and hopefully get you on the field for some practice rounds for your drivers.
One of the biggest issues in the 6 week schedule. For most teams the hardware build will take right up to ship date. Most hardware teams do not understand software takes lots of time, but since they can not see it like hardware leaving time for it just doesn’t happen.
Our teams tried to deliver on time but it didn’t happen, so we kept back Crio and ordered extra parts and continued to program.
I think your answer lies in the complexity of your robot. If you are just mapping motors to joystick values and switches (open loop), you should be able to design the code and implement it fairly easily at the regional.
If you are doing any kind of semi autonomous operation or closed loop control, you should probably look into setting up some kind of test bench with another cRIO, or figuring out a way to make some community tools useful. (Like the Kwarqs’ virtual robot or 111’s virtual driver station)
Also, if you are new(ish) to programming, it may be helpful to do some test coding on a previous year’s robot. While the control system isnt the same, many of the coding techniques you will use will be the same. For example, I have been using the same state machine code for arms/shooters/turrets/launchers for the past 3 years. (Don’t worry, we rewrote it every year. Its just basically the same exact thing.)
We still have the cRIO so I think we should pretty good. I guess my main problem deals with the complexity of our drive system.
Thanks for the suggestions and advice. I’ll be sure to check back if I need any help.
FYI, I have finally released the test harness.
http://www.virtualroadside.com/blog/index.php/2009/03/14/wpilib-test-harness-released/
Even though our team is not using the C++ environment and can’t use this test harness, I applaud you for putting one together. I had been thinking that there should be a way to emulate the hardware such that you can see what the program is trying to do. We use LabView and using the probes during run time on the robot has been great … so I am also wondering if there could be a generic CRIO emulator that, when run, would listen on the appropriate IP address and could be connected to either LabView or C++ dev environments.
How hard do you think that would be?
so I am also wondering if there could be a generic CRIO emulator that, when run, would listen on the appropriate IP address and could be connected to either LabView or C++ dev environments.
How hard do you think that would be?
That sounds like far too much work. 
First off, you would need a PowerPC emulator (which, there are some that exist, but I’m not sure how peripheral-agnostic they are). Second, you would have to figure out how the peripherals (ie, the FPGA) are mapped onto the system, and as far as I can tell most of that is totally undocumented (at least, undocumented to us). Then, you would have to implement the peripherals and such, and flash the emulated enivironment – at which point its not immediately clear if the license that we have for vxWorks and such allows you to run it on anything except for the control systems given to us by FIRST.
You’re probably better off checking out the link that Pikat posted – that seems to be a simple solution for the problem.