View Single Post
  #2   Spotlight this post!  
Unread 24-01-2010, 15:56
apalrd's Avatar
apalrd apalrd is offline
More Torque!
AKA: Andrew Palardy (Most people call me Palardy)
VRC #3333
Team Role: College Student
 
Join Date: Mar 2009
Rookie Year: 2009
Location: Auburn Hills, MI
Posts: 1,347
apalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond repute
Re: Any ideas on simulating robot to prototype code

I don't know how well Java would adapt to this, but I have written simulators in LabVIEW capable of testing the higher-level code for a robot arm. I could set positions of a state machine from the virtually-running code, then have the drawing loop draw each segment of the arm to an XY graph.

In 2007, we had code on the robot that needed an array of sensor positions for a state machine. We had a simulator in VBA (Excel) to allow us to set the end height of the arm, then slide it in and out and get the sensor values.

In LabVIEW, you could write an abstraction layer to have all calls to the WPIlib handled in common places and save/write them to global variable files, then you could run the VI's that actually do the work run by themself and test the IO by manipulating the global variables on the Front Panel. In Java, it would be trickier. This really depends on what you want to simulate; if you want to test your PID code then you really really need the real robot. If you want to simulate some code that handles semi-automatic robot arms, then you could simulate it in LabVIEW and then swap out the drawing code with PID code.

You cant disable the hardware, but you can just not listen to the hardware. If you have just a cRio, you can just not connect the IO and write it as if it was the real hardware. Then your code could do stuff and output it to the Dashboard, and collect data from the Joysticks, but not act on it. If you are not using the kit chassis, you could assemble the kit chassis with transmissions and only need to buy a new cRio, Jaguars, and motors, leaving you with a simple skid-steer drivetrain to test things that don't depend on shifting or specific traction, like testing some parts of the camera code or such. Depending on how old your team is, you could use a past robot and put a cRio in it, to test code not dependent on the physical robot (camera code is the best example). You need to remember that even a duplicate robot will not be exactly like the competition robot, so make sure it is easy to change parameters like PID gains for when you have the real robot. You might even consider having a "New Robot" variable that switches from one set of gains to another, those from the practice robot and those from the competition robot.
__________________
Kettering University - Computer Engineering
Kettering Motorsports
Williams International - Commercial Engines - Controls and Accessories
FRC 33 - The Killer Bees - 2009-2012 Student, 2013-2014 Advisor
VEX IQ 3333 - The Bumble Bees - 2014+ Mentor

"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack