Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)
-   -   Improving the experience of programmers and the effectiveness of code (http://www.chiefdelphi.com/forums/showthread.php?t=79353)

spartango 24-12-2009 15:09

Re: Improving the experience of programmers and the effectiveness of code
 
I share the same issue about hardware access being a bottleneck for testing....
In my experience the best way to get around this has been through simulation and hardware emulation...either at the API level or even at the device level.

For this year's competition, I think this might be something that we can actually achieve relatively easily at least for Java developers--
The squawk VM was run primarily on SunSPOTs(a sun embedded platform similar to a Mote) until very recently, so the guys at Sun Labs built an emulator for the SunSPOT known as Solarium. It works decently well, and for FRC we'd really only need to write our own Pseudo-WPILibJ (same methods, just no JNI calls for hardware)...and then we could run on top of this. Unfortunately this is an emulator, not a robot simulator

Alternatively, my team is writing a generic robot simulator that ties into the GRTFramework, such API calls to the GRTFramework are caught and used to manipulate Java AWT/Swing renderings on screen..its a lot of work to simulate a robot, but it might well be worth it.

I should also point out that labview has the awesome feature that if you use VIs appropriately, you can unit test MOST of them independently of the hardware (you end up feeding in values to a front panel or even through the VI inputs, but you dont actually need to deploy a lot of the code).

Greg McKaskle 24-12-2009 18:50

Re: Improving the experience of programmers and the effectiveness of code
 
I think that a WPILib level emulator would be a great start, and depending on the level at which the emulation happens, it could even run with the existing libs for all three languages. The way to do this on LV is to duplicate the libraries and place them into the vi.lib for the desktop target. This would result in broken VIs because there is no FPGA. With a bit of work, though, the FPGA could be replaced with an I/O engine that has hooks for external code to update the values based on a given robot.

When VIs in the project tree are under the cRIO, they load with a cRIO vi.lib. When they load desktop, they open with a desktop vi.lib -- which doesn't contain a WPILib implementation. So once one exists, the rest is pretty straightforward.

It didn't get done this year, but there is always next.

Greg McKaskle

kamocat 25-12-2009 00:56

Re: Improving the experience of programmers and the effectiveness of code
 
Quote:

Originally Posted by Greg McKaskle (Post 890498)
I think that a WPILib level emulator would be a great start, and depending on the level at which the emulation happens, it could even run with the existing libs for all three languages. The way to do this on LV is to duplicate the libraries and place them into the vi.lib for the desktop target. This would result in broken VIs because there is no FPGA. With a bit of work, though, the FPGA could be replaced with an I/O engine that has hooks for external code to update the values based on a given robot.

When VIs in the project tree are under the cRIO, they load with a cRIO vi.lib. When they load desktop, they open with a desktop vi.lib -- which doesn't contain a WPILib implementation. So once one exists, the rest is pretty straightforward.

It didn't get done this year, but there is always next.

Greg McKaskle

I can tell you that I had plans for making one this summer, and I simply ran out of time.
I was doing it fairly low-level, and I don't think I got much past PWM and solenoid. (I wasn't sure about how to implement the analog trigger).
I think the GUI would be a key in making an effective emulation.

What I did was use conditional disable structures. I quickly found how long it took to place and configure them. I also had some trouble with placing the preconfigured conditional disable structures *around* a selection on the block diagram.

The way you're talking about it, it sounds like you can specify different dependencies for different targets in a project. How would you do this without creating conflicts and recompiling the VI whenever you switch between the two?

Anyways, what I've done can be found under "cRIO simulation" here:
http://kamocat.com/programming.html#misc

Greg McKaskle 25-12-2009 08:33

Re: Improving the experience of programmers and the effectiveness of code
 
You'd load the VI under different targets, and it'd load with different libraries. If the libraries have the same connectors, same typedefs, etc, then no compile is necessary. If something is different, say some parameter is added to WPILib only for emulation control, then your VI recompiles.

In reality, LV does what is called proptypes each wire, and each node move. It is the syntax portion of the compile. When you hit the run button or save, it finishes the compile. What I'm getting at is that the reason many people assume LV is interpreted is because the compile is very fast, so even if that occurs, it is no biggie. I'm pretty sure that the top level of WPILib will not change at all from the target.

LV also allows the VIs to be loaded into more than one target at a time, so you could even have both open and running at the same time.

Greg McKaskle


All times are GMT -5. The time now is 14:23.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi