cRIO Emulator?

[rickross]

Originally Posted by spartango

I've been hacking around this issue by using the SunSPOT emulator(runs squawk)...
Basically what I have is a copy of the GRTFramework(http://code.google.com/p/grtframework/), which wraps around all the WPILib stuff. The change I make is that the copy of the framework I use has been "neutered"...instead of actually calling WPILibJ, I update/read the state of a 'Robot' object that has GPIO and analog and PWM and so on.. its an emulation, but keep in mind that it doesnt simulate the actual hardware(no real sensors). I can simulate inputs but its not exactly pretty.

Very cool project, spartango. I hope you'll keep working on this some more to make it a generic cRIO emulator. It could have a cool dashboard to show the state of the 'Robot' object, and possibly even get visual. It would help a ton of people.

[techhelpbb]

I am a mentor for Team 11 and we've run into this problem as well.

We have more than a dozen students to teach to program in Java, some far more experienced than others in Java itself, and while we have multiple cRIO they are scattered in other robots and systems that don't lend themselves to the inexperienced writing code (too much risk of damage).

In the interim one of the team leaders and an increasing number of the more experienced students worked up emulation for the joystick and victors. It's rough, it's also very early stages.

However, basically you can create X and Y joystick input and feed it to virtual victors that display their percentage of pulse width in some windows.

It's very light on documentation right now and it'll take some effort to install it (it was tested with NetBeans), but I'll submit the link to forum for anyone that it might help.

http://code.google.com/p/frcjcss/

Eventually we hope to add some interesting features to this, but I don't want to pressure the students writing this too much right now. So until we get things a little more under control I'll let the students control the flow of effort at their pace.

Eventually I will say it would be possible to tweak this to produce virtual encoder feedback and even graph the various outputs versus time so that complicated processes like PID loops are a little more apparent. Something I think would be invaluable as last year one of our students spent a ton of time working up an entirely new and complicated PID style software for our robot and it's very hard to explain what it does and when without graphics.

[davidthefat]

Now I think a more practical solution is a code repository. You can code for the robot at your house then upload it to the repo, then a fellow coder with access of the robot can test out your code and sent a a bug report or even fix the bug for you. Because no matter how good of an emulator you have, it is just emulating, it will never behave exactly like a real robot will.

[AustinSchuh]

David,

I think that the goal here is to let new programmers work out the simpler code, without risking breaking the hardware. Of course, you can't tune a PID loop on it and expect it to work the exact same on a real robot, or tune the drivetrain to feel nice to drive, but if a new programmer accidentally sets the bot to spin in circles infinitely by accident, that won't cause any problems in the simulation. Once the programmer and mentors feel comfortable with the programmer's abilities, the simulator won't have as much value (without a lot of work being put into it to making it accurate).

When I try out new controls algorithms, I like to simulate them myself before putting them on a real bot. And I know what I'm doing. Simulation helps cheaply catch simple bugs and generally has a faster test cycle than testing on a real robot.

[techhelpbb]

The other problem with testing with the real cRIO is access.

Even if you can send code to a remote repository via HTTP or FTP, someone really has to be nearby to monitor the robot.

Even if you can monitor the robot with video and capture the control terminal's display and controls, what happens when the battery dies? Even if you can build a float charger to keep the batteries alive, someone really needs to be there to put a stop to things if they get out of hand.

Even as a veteran team we can't really expect someone to be available at all hours of the day and night for this purpose. We have sent whole robots home with people but obviously even a control system board with a few motors is not exactly something you want to haul all over with you.

Having an emulator like this allows people to tinker when they feel like without dragging resources of all types into it.

For now the educational advantage is that the students with the least fundamentals can use this whenever they have time and without any sort of major outside pressure.

The more advanced students programming this emulator get to learn the details of the control systems. Things like how the analog joysticks have noise and why that noise is there. After all, to make a decent simulation you want to simulate even the undesirable characteristics of the system.

In effect the more advanced students are challenging the other students who are reaching their level and teaching themselves in the process. The people using the emulator can in turn learn from the emulator the sort of subtle things that they can expect when programming the real thing.

Or course in the real world there will be additional sources of problems. Things like stuck actuators, impacts with objects, overheating speed controls, motors changing RPM on various surfaces in various directions, delays introduced by the wireless network, users smashing the joystick around, and batteries dropping dead. Hard to simulate some of that. However, that just means that after this level they are prepared with a solid foundation to chase that sort of quirk.

Additionally this provides a sort of proof of concept that is good in cooperative environments like ours where we have enough students for multiple divisions of labor. If there's doubt that a chuck of code isn't basically functional we can toss it into simulation and settle doubts.

[Alexa Stott]

Originally Posted by AustinSchuh

David,

I think that the goal here is to let new programmers work out the simpler code, without risking breaking the hardware.

One word: e-stop. Seriously, you should never run your bot without it. If you see something going wrong, simply stop it.

[techhelpbb]

Originally Posted by Alexa Stott

One word: e-stop. Seriously, you should never run your bot without it. If you see something going wrong, simply stop it.

Sound advice in all automation. However, electronics can be damaged before you can slam the button and even the average human reaction time can be sufficient. Worse you may not notice the increasing temperatures of the speed controls as you're keeping your hands clear.

http://www.humanbenchmark.com/tests/...time/stats.php

We have some assemblies in which we have multiple motors mechanically linked and the speed controls can pay dearly from trivial programming errors.

[jhersh]

Originally Posted by techhelpbb

We have some assemblies in which we have multiple motors mechanically linked and the speed controls can pay dearly from trivial programming errors.

If you use Jaguars, they will save themselves. They measure current and case temperature to decide if they can continue driving the attached load.

[AustinSchuh]

Originally Posted by Alexa Stott

One word: e-stop. Seriously, you should never run your bot without it. If you see something going wrong, simply stop it.

In 2007, we had an arm that moved at 20 RPM, driven by a CIM. I flipped a value (long night...) and it went for it, trying to slam through the ground. I had less than 1/2 of a second to hit the disable button before it would have slammed into the ground under full power. Had my hand not been on the controls and my trigger happy kill reflex on full at that point in time, we would have had a lot of repair work left to do.

So, while a kill switch helps, it is no magic bullet. I'm not sure I would want someone learning how to program with that arm, since I would have to be continually on the kill switch, ready for their next mistake. Putting them on a simulator until they were further along would make the experience a lot more enjoyable for both of us.

[DaveFrederick]

I am very interested in the JAVA CRIO emulator.
Could I get a little guidance on how to get it working?

I have reviewed all of the data on the two web links:
http://code.google.com/p/grtframework/
http://code.google.com/p/frcjcss/

I have installed the plugin:
org-grtframework-grtframeworktemplate.nbm

I have unpacked and loaded the project: CurrentBot.zip

But I'm stuck and am not sure how to proceed.

Thanks in Advance,
Dave Frederick, Mentor Team 1895 - Manassas, Va

[bakketti]

Originally Posted by DaveFrederick

I have unpacked and loaded the project: CurrentBot.zip

But I'm stuck and am not sure how to proceed.

Dave- I just got it working the other week. I created a new Netbeans Java Application (not a FRC Java program) and named the project "Robot". This is the same name as the main project in CurrentBot.zip (check me on that name, I don't have my computer in front of me right now). Once you have a new project import all of the files from CurrentBot.zip into your project. You may have to mess with the files a little bit to get it work. After you import the files, you should be ready to go! Add some robot simulation code to the main() routine inside an infinite while loop and everything should work.

Note that this may not be the optimal setup. I'm not affiliated with the project and just messed with the files until I got it running.

[DaveFrederick]

bakketti,
Thanks for the reply.
Could you expand on how you imported the GRTRobot project files into your new Java Application?

I searched the help files and Google for Netbean import capabilities but am not proficient in Netbeans or Java to understand the approach. Considered copying the source files to the new product but this seemed wrong.

Thanks,
Dave Frederick

[bakketti]

Hey sorry for the slow response. Just to be clear, I was speaking originally about the frcjcss project, not GRTFramework. I haven't messed with GRTFramework at all yet. But for frcjcss, I believe I copied the java files directly into the package folder on my C drive. Netbeans will automatically recognize the files and they will show up in your project. Hope this helps.

[techhelpbb]

Originally Posted by DaveFrederick

I am very interested in the JAVA CRIO emulator.
Could I get a little guidance on how to get it working?

I have reviewed all of the data on the two web links:
http://code.google.com/p/grtframework/
http://code.google.com/p/frcjcss/

I have installed the plugin:
org-grtframework-grtframeworktemplate.nbm

I have unpacked and loaded the project: CurrentBot.zip

But I'm stuck and am not sure how to proceed.

Thanks in Advance,
Dave Frederick, Mentor Team 1895 - Manassas, Va

We've been a little swamped with the kick off event and all.
I decided to wander back in here and found this post.

I'm going to direct this to the attention of the lead student.

Sorry for not catching it sooner.

Documentation is everything

[Patrick Chiang]

If you guys have the time, can you also please explain the classes in the networking package? It seems like they're some sort of info communication between your dashboard computer and the robot.

However, I don't see it being implemented anywhere else in your project. I would appreciate a quick example of how I could implement it (or how you implemented it last year) if I wanted to build a custom Dashboard. (which I'm assuming it's for, right?)

Thanks!