Teams happy with Wind River Workbench?

[ethanmurai]

With half of our programming team having C/C++ experience and the other half being rookies, it may have made more sense to have used WRWB instead of LabView. However, the powers that be believe that C/C++ support is going to be phased out (personally,I don't feel that this would happen anytime soon, if ever) so this year we used NI LabView. This caused more than a few grumbles from veterans (myself included). I still have a few complaints about the amount of time it takes to implement simple operations in LabView vs the same operations in C/C++ (i.e. assigning the sum of two numbers to a variable), however, the connect-the-dots sort of layout makes it easier to read and document VIs than .cpp/.h files (not that half of our code is documented... ).

[EricVanWyk]

Originally Posted by ethanmurai

With half of our programming team having C/C++ experience and the other half being rookies, it may have made more sense to have used WRWB instead of LabView. However, the powers that be believe that C/C++ support is going to be phased out (personally,I don't feel that this would happen anytime soon, if ever) so this year we used NI LabView. This caused more than a few grumbles from veterans (myself included). I still have a few complaints about the amount of time it takes to implement simple operations in LabView vs the same operations in C/C++ (i.e. assigning the sum of two numbers to a variable), however, the connect-the-dots sort of layout makes it easier to read and document VIs than .cpp/.h files (not that half of our code is documented... ).

Ok, seriously guys - WHERE DO THESE RUMORS COME FROM?

It ain't happening. I promise. C++ is here to stay. LabVIEW is here to stay.

[Pancake]

I'm the only person who programmed the bot. I loved being able to use C++ on the robot and oop Also, the remote console feature for the cRIO is simply amazing - I finally discovered that feature the two weeks before the end of building the robot.

However, a frustration of mine was not being able to separate header files and C++ files, like in Visual Studio

I personally don't like programming with pictures :\

[Alan Anderson]

Originally Posted by Pancake

I personally don't like programming with pictures :\

If it was just a matter of text vs. pictures in a procedural programming language, I'd agree with you. However, LabVIEW is a dataflow programming language. Once it clicks, "wiring it up" graphically is a very natural and intuitive way to do things.

I would have been very happy to experience the quick compiling and ease of posting code snippets with C++ and WindRiver, but I don't regret choosing LabVIEW as the programming environment for the TechnoKats this year.

[virtuald]

Originally Posted by Pancake

Also, the remote console feature for the cRIO is simply amazing - I finally discovered that feature the two weeks before the end of building the robot.

The console has always been very problematic for our team -- there seems to be a tendency to kill the program's response time if you send too much to the console, and the output always seems to be delayed also. Same with writing to files on the cRio

However, what is *really* amazing is the DriverStationLCD class, which allows you to print output to the DriverStation. We've implemented a set of maintenance/diagnostic related routines using a menu system that uses the LCD for output and a thumbwheel and switch on the DS for input. We also have it setup where there are multiple different ways to configure the joysticks (driving according to the robot direction, driving according to the field position, etc) using a thumbwheel switch, and having it output the currently selected control setup and the robot heading relative to the field has been quite useful.

Originally Posted by Pancake

However, a frustration of mine was not being able to separate header files and C++ files, like in Visual Studio

I'm not sure what you're talking about. The C++ compiler supports using header files and C++ files. Just because the default demo doesn't come like that, doesn't mean you can't do it.

[byteit101]

Originally Posted by virtuald

I'm not sure what you're talking about. The C++ compiler supports using header files and C++ files. Just because the default demo doesn't come like that, doesn't mean you can't do it.

In VS, It has virtual folders in the "project explorer" that seperate resources, CPP files, and H files

[virtuald]

Ah, thats what you meant. Personally, I actually find those to be rather annoying for large projects, especially when you get into large projects.

I'm not sure how complex your bot is, but we have around 50 or so seperate cpp/h files spread over 6 directories.

[byteit101]

wow! 50?! what is all that for?
we just have
myrobot.cpp
camera.cpp/h for camera functions
mech.cpp/h for mechanism control
DriverStationLCD.cpp/h just if we want to use this
DriveDampen.cpp for ramping up drive code
for a total of 8 files. did you make seperate classes for all sensor access, or what? (that seems a bit excessive for 25 different files)

[virtuald]

We are using a swerve drive this year, with all 4 wheels independently controlled. So we had to write code to control all of those (essentially creating servos using an encoder and a motor). One of the big problems with swerve drive for us is that we haven't agreed on the best way to control it using joysticks and such. As a result we have about 4 different ways that you can use to control it.

We also are using a layered approach to control, where all of the joystick/user interaction takes place in a 'movement control' class selected by a thumbwheel switch on our DS, that talk to a 'DriveController' and give it speed/angle/rotation parameters. The drive controller sends the input to various drive classes which can act as filters for the values (or record them), and then finally down to the actual class which controls the motors and translates the speed/angle/rotation parameters to motor values and servo angles. Its similar to RobotDrive in WPILib, but quite different since we separated out the stuff that talks to the user and the stuff that talks to the motors (which is a far better design and more extensible in my opinion). While it sounds complicated, it makes writing autonomous mode code extremely easy, since it is just a form of a 'movement control' class.

There is also a 'maintenance mode' controlled by a switch on the DS, that allows us to run various diagnostics and calibrate our servos, with user feedback displayed on the LCD on the driver station.

There are also probably about 10 files that just have utility functions (like missing math functions/constants, various filters and serialization stuff, a wrapper around the Joystick class to give it a better deadband, and a class useful for doing delayed actions).

I've attached the 'collaboration diagram' generated by Doxygen for our code. Its really quite logical, but there is a lot of stuff there.

I will actually be releasing our teams code in the very near future (as we are done for the season now that the Boston Regional is over), as soon as I finish work on my WPILib Test Harness GUI (its quite useful for some types of debugging, and lets me run code on my home computer -- but not quite ready for prime time).

[byteit101]

wow! you must have had time before the season to learn the code, and a very good programming team! we learned about it in the season. I would consider our team good (we have 6 people), even though 1 hardly ever comes, 2 barely know about coding this years control system, 1 knows some C++, but would have a hard time modifing our code, 1 knows most of the code, and I know all the code (I programmed most of the actual robot code) for a total of 2 1/4 people (productivity soars!) I would be interested to see your code, it sounds a bit much, but very OOPy sounding. WPILib Test Harness GUI? like a fake cRIO? that would be cool && usefull! I am also planning to release our code after the Boilermaker at Purdue in the spirit of GP and helping other teams learn more about C++

[virtuald]

Originally Posted by byteit101

wow! you must have had time before the season to learn the code,

Actually, the key here is to just have zero life for 6 weeks. Reading WPILib helps a lot too.

and a very good programming team! we learned about it in the season. I would consider our team good (we have 6 people), even though 1 hardly ever comes, 2 barely know about coding this years control system, 1 knows some C++, but would have a hard time modifing our code, 1 knows most of the code, and I know all the code (I programmed most of the actual robot code) for a total of 2 1/4 people (productivity soars!)

We have two people on our programming team: me and a student who knows C to some degree, but struggles with OOP and classes. Unfortunately I did 95% of the coding in the last 2 weeks of the build season due to our robot not being assembled until 2 days before shipping. However, he *did* create/code a really neat way of controlling the robot -- using the gyro, we use the joystick to move the robot relative to the field (ie, pointing the joystick up makes it go north, pointing east goes east... etc).

My goal for the offseason is to use the code and help him (and others who might be interested, since he will be a senior next year) to learn more about OOP and such.

I would be interested to see your code, it sounds a bit much, but very OOPy sounding.

Its OOP in very much the same style that WPILib uses. The code is very straightforward code too, it only took 3 hours to implement the primary framework for it.

WPILib Test Harness GUI? like a fake cRIO? that would be cool && usefull!

Bingo. At the moment the driver station interface works quite well, and there is some support for motors and such. I've been putting in stubs for other stuff, my goal is to release it and see what others think, and possibly set up a sourceforge project for it. I've found it extremely useful for finding things like uninitialized variables and bad pointers, and for creating the driver station LCD user interface.

[P.Svilans]

Wow!

My project consists of the following files:
myRobot.cpp

Pretty massive project, huh?
Then again, we only had 2 programmers, and it's our first year in this competition, so...I guess I'm pretty happy. Plus or robot's got a simple driving mechanism, and all the functions we do in operator control aren't worth writing up seperate classes for anyways.

The cRio emulator's a good idea! Saves time loading the program into the robot every time, I'm guessing?

I'd like to see it in action! Maybe for next year or something...(I'm definitely not experienced in C++ (I'm more AS3.0), but C++ isn't a problem so far. Also, looking over some of your code would be nice!

P.

[virtuald]

Ok, the WPILib Test Harness/simulator/whatever is finally released, you can get it/see it at http://www.virtualroadside.com/blog/...ness-released/

I've also posted our teams complete source code tree for 2009 on my FRC software resources page, http://www.virtualroadside.com/FRC/

[DtD]

Our team opted to use C/C++ because our programmers were already fimilar with C++, and not LabView. However, the Windriver interface was EXTREMLY annoying, it caused tons of problems that ended up making our robot's code much less than it could've been. We wasted like 1 week on fighting Windriver, another 1 fighting the cRIO, and another 2 fighting the documentation.

~DtD

[Foda]

I'm not at all happy with WRW. I've found it using 500+MB (I have 2GB) of ram when just opening a small project. I can't even do anything because I constantly get "Out of Memory" errors. Our team has noticed similar problems with slow startup speeds. Visual C++ Intelisence is much better. The help manual is also not helpful at all (it starts a webserver through my browser?! what?!). We wish we could use VC++...