GUI WPILib Test Harness Released

[virtuald]

If you're interested, I've created a 'test harness' for the C++ WPILib, that allows you to run the robot code on your PC (and theoretically Mac/Linux are supported if someone makes the build files for it too). Theres a lot of stuff it supports doing, and a lot of stuff that it doesn't support yet. Hopefully if theres enough community support we can make it support just about everything.

Its been very helpful for me, even in its early stages -- I've used it to find bugs in my program and in WPILib as well. For more details/screenshots and of course the source code (GPL), see my blog: http://www.virtualroadside.com/blog/...ness-released/

[Jared Russell]

I think a *lot* of people are going to be VERY happy about this. I look forward to testing it out!

Thanks!

[Shinigami2057]

This is an awesome idea. I hope to contribute to this in the near future!

A few comments as to what I've seen so far:

• It's a bad idea to use wxWidgets library calls in the simulator. If you ever plan on moving to another GUI toolkit, you can't just rip out the current GUI and add a Qt or GTK interface without drastically changing your simulator. Also, what if someone wants a console interface to the simulator? I'm more than willing to help on this front; it looks like you only need thread synchronization from wxWidgets, which is very easy to port.
• A better approach in the long run, although more difficult, would be to implement the FPGA interface (the ChipObject classes and whatnot) rather than editing WPILib directly. Then WPILib can be run directly without need for modifications (that can easily be buggy).

Another good thing to implement would be a unit testing framework for WPILib.

[virtuald]

Originally Posted by Shinigami2057

It's a bad idea to use wxWidgets library calls in the simulator. If you ever plan on moving to another GUI toolkit, you can't just rip out the current GUI and add a Qt or GTK interface without drastically changing your simulator.

I've kept this in the back of my mind when creating it -- this is why the stuff that does the actual work all sits in its own set of files/classes, as opposed to being totally intertwined with the GUI window.

As for abstracting the GUI itself away -- I feel this is rather silly -- the whole point of wx is to be cross platform (in fact, it uses GTK in Linux), and trying to abstract over that (which is already an abstraction) is just a bunch of unnecessary work that I didn't feel was necessary.

Besides, 90% of the code in the GUI window is just fluffy glue that moves information from the GUI controls to the control interface class (and vice versa). There isn't really any real work involved there.

You have to draw a line somewhere, and I placed my line in the Simulator directory classes. Feel free to draw the line somewhere else though, and send a patch.

Also, what if someone wants a console interface to the simulator? I'm more than willing to help on this front; it looks like you only need thread synchronization from wxWidgets, which is very easy to port.

You're more than welcome to separate out the synchronization stuff, it should be quite trivial to do. There is also a line in Simulator::SimulateStep() that sends an event to the main window, I suspect that could be abstracted away quite easily, in the same way that the synchronization stuff would be.

A better approach in the long run, although more difficult, would be to implement the FPGA interface (the ChipObject classes and whatnot) rather than editing WPILib directly. Then WPILib can be run directly without need for modifications (that can easily be buggy).

A good number of the WPILib classes don't depend on anything in the hardware, and so I've tried including those verbatim when possible (though, it wasn't my original goal to do this so some of the objects have a lot more chopped out of them -- my point of view on this evolved as time went on). At some point I will probably go back over the classes and reevaluate how I chopped them up -- one in particular that should have been done better is the chopping of DigitalModule/AnalogModule.

You will not be able to get it done totally unmodified, due to some compiler quirks (for example, Visual Studio will not allow you to have non-integer static constants). Also, due to the looping nature of the code, you have to find somewhere to stop the loop, so modifying IterativeRobot and SimpleRobot is necessary (a very tiny modification in each).

The downside of abstracting at the fpga class level is that all of the ChipObject stuff is totally undocumented (even though its typically obvious what the function does), and is subject to significant change at the whim of the fpga designers. I felt abstracting at the WPILib level was subject to less change, and would be easier.

Of course, feel free to do it differently. Send patches.

Another good thing to implement would be a unit testing framework for WPILib.

If you're talking about WPILib itself... well, I would hope they have some kind of testing that they do for it that they just don't give to us (but, thats probably not the case).

If you're talking about using this to create something that you can unit test your robot code in it, then I would agree thats probably a good thing to do. I don't have a ton of experience in this area, so I would rather defer this work to someone who has a better idea of useful things a unit testing framework should have.

[xtreampb]

I was wondering if eaither of yall could show me how to set up wxWidgets for Microsoft Visual C++ 2008 express.

Thanks

~xtreampb~

[virtuald]

http://wiki.wxwidgets.org/Microsoft_..._C%2B%2B_Guide

Or to summarize what you'll find there:

• Download/install the source code (you'll want the wxMSW installer)
• After installation, open the workspace: build\msw\wx.dsw
• Build it in Debug Unicode mode and Release Unicode mode

My code assumes that you have wx installed at c:\wxWidgets -- typically what I do is setup a symbolic link to that directory using the Junction utility, but you can just directly install it there as well.

You can also use wxPack for a precompiled version of wx, but I don't have any experience with that.

[DaveFrederick]

Dustin,
Bravo !!!!
Thank you for your efforts on this simulator.
I have found it very useful in learning how to use the WPI library.
Our main Student programmer is a senior this year so I figure as a Mentor I need to learn how to develop the software so I can teach next years students.

Please keep everyone informed as to when any updates are released.

Regards,
Dave Frederick, Mentor, Manassas, Virginia Team 1895.

[virtuald]

Yeah... I'm sure I'll be updating this once the build season starts up. Haven't touched it since last year though. At some point I need to make a Google Code project for it...

[brian3795]

Any updates on this? Seems a shame that interest in this has fallen off...nothing more bothersome than having to actually have the cRIO present and accounted for when testing code.

[virtuald]

Originally Posted by brian3795

Any updates on this? Seems a shame that interest in this has fallen off...nothing more bothersome than having to actually have the cRIO present and accounted for when testing code.

I really haven't had a need (or motivation) for it recently, since our robot code has been quite simple the last two years, so I haven't done anything with it. Feel free to improve/update it, however.

[brian3795]

Originally Posted by virtuald

I really haven't had a need (or motivation) for it recently, since our robot code has been quite simple the last two years, so I haven't done anything with it. Feel free to improve/update it, however.

Looks interesting! Got it up and running, so I'll see what I can do with this.

[jwakeman]

I also downloaded this and got it up and running this past weekend. I agree this project has some real potential. Dustin, Brian, what do you see as the next steps/features to implement for the project? I would also like to help!

[virtuald]

Originally Posted by jwakeman

I also downloaded this and got it up and running this past weekend. I agree this project has some real potential. Dustin, Brian, what do you see as the next steps/features to implement for the project? I would also like to help!

Did you use the version in SVN or the last file release? I think it's slightly broken right now... though I don't exactly recall where I left the code.

I believe the thing I was working on before I dropped it was porting the rest of the WPILib components to the test harness, and trying to use more of the actual source code for WPILib in the work.

If you guys want to do work on it, join the FIRSTForge project and I'll give you SVN access.

[jwakeman]

I downloaded it from the file releases, WPILibTestHarness-0.1.1. It seemed to be working fine. I was able to run the DefaultCode project and see the solenoid lights flashing in a nice sequence. I am a member of FIRST forge as jwakeman. I can't guarantee I will be submitting anything anytime soon but I would like to be able to get the latest code from the svn to study.

One question for you though. I can see how you can drive outputs and see the solenoid light for example. But if I declared a digital input for example how would I drive the value of that input? Is there some way to drive the digital input high/low from outside of the robot code under test? Or is that a TODO?

[brian3795]

I tried to browse the source, but I was denied anonymous access. I'll see about registering an account.

Jwakeman, I've got this compiled using VC++ Express 2010 (for whatever reason, I was unable to download 2008) as well as the latest dev version of wxWidgets. There were a few minor changes required. Right now, I'm getting error messages on the PWM output widgets (all the other widgets seem to be present and accounted for). I'd like to try compiling against the latest WPILib code.