Teams happy with Wind River Workbench?

[gvarndell]

Amongst teams using WRWB (C or C++) for development, are there any that have no regrets about the choice?
If your team is pleased with WRWB, could you please provide some comment as to why your team chose WRWB over labview?
Also did you have a team member (mentor or otherwise) with previous vxWorks experience?

[mahmosh]

we chose windriver becuase our experience on c/c++ ... and the last year we use c and have more success.
if u don't have any experience you should use labview

[byteit101]

I have tons of experience with eclipse (Java and C++), what WR is built on. I also have experience in C, C++, C#, and the OOP style.

[Bongle]

None of my team's students had experience in either labview or C/C++, but we had me (full-time C/C++ programmer) and a few other mentors who had dabbled in C++. With this in mind, we decided that:
1) We were bound to hit roadblocks in either environment. Think bizarre compile errors, or "why is it doing THAT?!" kind of events.
2) People with lots of experience in a given environment tend to know how to get around roadblocks in that environment
3) Thus, choosing the environment that we had background in would be the most prudent choice.

Another way to look at it is that labview probably has a higher "top speed of development", but accelerating our team to that rate would take long, because not only would the students be learning, but so would the mentors. With C/C++, we can hit the ground running, programming wise. Our plan is to compete this year with C/C++, then re-do the robot's program in labview so that next year we're ready to do it all in LabView. See attached image for a pictorial version of this paragraph.

[rogerlsmith]

I am very happy with Wind River Work Bench. I am a co-mentor on our programming team, and both of us mentors have experience with C/C++. We used eclipse with WPILib last year and were fairly successful.

[virtuald]

We are in the same situation with Bongle: I and other mentors have a lot of experience using C/C++, and no experience using LabView at all.

However, eclipse and WindRiver annoy me quite a deal. I've done a lot of work with visual studio in the past, and despite looking similar, the environments are both rather different (in particular: shortcut keystrokes, eclipse's millions of tabs, autocomplete, and the whole 'workspace' paradigm to name a few). The WindRiver-specific stuff seems to be mostly semi-intuitive, except there are a few places where at first it seemed like to do particular actions a particular option seemed like the way to do it -- but then it turns out it does it, but in a totally different way.

Despite those annoyances, as I am learning to deal with them I'm becoming more productive.

One thing we really love however is the ability to setup our laptops on a table in the gym, and sit there and do just about everything we need to do wirelessly without having to constantly walk over to the bot. :)

[virtuald]

Also, I am 85% happy with WPILib -- I think they did a great job abstracting a lot of the common functionality away, and it makes really simple things really simple. There are a few places where I think I would rather have some of the objects setup a bit differently, but thats ok. Just waiting for them to open it up so we can submit patches... :p

[Tom Bottiglieri]

I'm growing increasingly frustrated with the WRWB package. We have spent most of our time setting up the workspace and fixing little bugs that pop up. It seems every time we are about to get a nice piece of code to run, Workbench (or something in the cRIO) breaks. We are currently having an issue where the cRIO keeps switching between system and user mode. Any ideas how to stop that?

Does anyone know if there is a definitive guide to setting up Workbench? It seems the new LV 2 update and cRIO image v7 broke our existing settings.

[virtuald]

I do agree -- getting the workbench setup properly is a pain. However, once you get it setup correctly the first time I have personally found there is very little that needs to be changed (except for minor idiosyncrasies ).


Does anyone know if there is a definitive guide to setting up Workbench? It seems the new LV 2 update and cRIO image v7 broke our existing settings.

Go to C:\WindRiver\docs\extensions\FRC .. theres a bunch of magic in there... updated versions of the documents that are only posted online in their old forms (which is really annoying, IMHO). "C Programming Guide for FRC.pdf" has the information you want.

[comphappy]

We are loving it, we are programming up a storm here in it, with the only thing slowing us down being the incomplete manual. Someone posted a new doxygen output which in addition to the source fills in any of the wholes. The examples are ok, but they do do some things that are kind of frowned upon in terms of clean code (i.e. put things in a cpp file that really should be in a header). I spent the time from Atlanta announcement on testing labview, and even attended a training, and really did not like it, I spent way to much time just trying to figure out the most basic things in c in labview. On the otherside NI has made some great processing libs and tools for Labview.

On another not, I was speaking to a relative who is a lead engineer for a major consumer and avionics electronics company, and what he told me is that they are having a hard time finding people in the United States that have the skills to do the programming, they will never be using labview in there products they will be using C. Right now there solution has been to hire people from India for SKILL not COST. From that persepective which is better to prepare you for the workforce?

[darkorbit]

We chose WindRiver over lab view because most of our programmers know c/c++. Most of us felt that me might as well work with something we can code in instead of learning something else.

[Redneck]

599 is the same situation most of you - we went with Wind River because our programmers and mentors have lots of C experience and little to no LabView experience. I'm fairly happy with Workbench since it's basically Eclipse and I've been using that for most of my own coding for a bit now. It's got a few quirks that really annoy me but there are enough nice features to balance out.

[Felipe Sagui]

Our team 1382 started to learn and test both. We always were programming on c/c++, but on this year we chose Labview because it's very useful, not only on FRC.

On Labview we can make graphs and others indicators with sensors signals. We think with it, the code problems can be solve fast and better.

[HandyManDan]

Our team is having trouble with the WindRiver compiler. Can you please post the location of the header files for the C++? I need to verify we installed the product correctly.
Thanks

[virtuald]

Have you tried to compile one of the examples? A practice we've adopted is any project we create is derived directly from the SimpleTemplate example... its easier for debugging multiple different programs at once, since it makes it easier to find in the module list for things to unload...

[HandyManDan]

Yes we have, we even tried a simple hello world. The compiler can not find cstdio.h and the only one we could find is under a jre directory. Where are your system .h files?
Thanks in advance for answering.

[virtuald]

cstdio.h? Which example are you compiling... have you tried the FRC examples (the other ones won't work, AFAIK).

[HandyManDan]

I'll give it a try. Can you do a search on your machine for iostream.h and tell me where the file is located? That would be a really tell me alot.
Thanks

[virtuald]

There is no iostream.h , thats the old style header and should not be used. iostream is what you're looking for.

There are 6 include directories on the project.

C:\WindRiver\vxworks-6.3\target\h
C:\WindRiver\vxworks-6.3\target\h\WPILib
C:\WindRiver\vxworks-6.3\target\h\coreip
C:\WindRiver\gnu\3.4.4-vxworks-6.3\x86-win32\lib\gcc\powerpc-wrs-vxworks\3.4.4\include
C:\WindRiver\gnu\3.4.4-vxworks-6.3\x86-win32\include\c++\3.4.4
C:\WindRiver\gnu\3.4.4-vxworks-6.3\x86-win32\include\c++\3.4.4\powerpc-wrs-vxworks

If you're just starting out with a new project (especially without any prior C/C++ experience) -- if you need to include anything other than WPILib.h you're probably doing something wrong.

[HandyManDan]

I'm one of the mentors. It looks like the group did not install the WindRiver product correctly. The WPILib.h file includes IOStream, IO, and many others. We get compilation errors when trying to build the samples but, given the information you just gave us, the issues we are having are obvious. I'll have them reinstall so we can get off LabView.
Thanks for all your help.

[virtuald]

The WPILib.h file includes IOStream, IO, and many others.
Thus why one only needs to include WPILib.h ;)

[Cocoa]

I guess we choose WRWB since we have a few UNIX developers on the team. :/ Some help that was, running on windoze.

[s()n_of_@_g.U.n]

I don't really like Wind River or LV. I rather just stick to C/C++ progamming. Also, does anyone know if we're switching just to LabView next year?:confused:

[gvarndell]

I don't really like Wind River or LV. I rather just stick to C/C++ progamming. Also, does anyone know if we're switching just to LabView next year?:confused:

I don't know, I hope not.
But don't be surprised if Wind River pulls the plug on FIRST next year.

That said, I do find it curious that you don't like Wind River yet say you'd prefer to stick to C/C++ programming.
What is it about Wind River tools that makes you think it's something other?

Basically, you have (for free) world class cross compilers, Eclipse IDE with powerful debugging and analysis (static and runtime) tools, and the most robust realtime operating system in the world.
What's not to like?

And I don't want to knock NI, but the reality is that there's very limited job market potential for Labview programmers -- and that's not going to change.
I wanted my daughter involved in FIRST so she could learn software engineering in a hands-on way.
I do not want her to be a Labview programmer.

[Alan Anderson]

And I don't want to knock NI, but the reality is that there's very limited job market potential for Labview programmers -- and that's not going to change.

I'm curious to know where you find this to be a "reality". In my experience, LabVIEW programming is very widespread, both in education and in industry.

[gvarndell]

I'm curious to know where you find this to be a "reality". In my experience, LabVIEW programming is very widespread, both in education and in industry.

Go to monster.com:
search for -- "software engineer" labview. (26 over the last 60 days)
search for -- "software engineer" c++. (1010 over the last 60 days)

I really have no axe to grind here.
I once did an automated circuit board test system for a client --using LabWindows CVI (I think that's what it was called).
It was great for quickly putting together a UI with knobs, sliders, dials, and meters.
You use the right tool for the job at hand.

[EricVanWyk]

And I don't want to knock NI, but the reality is that there's very limited job market potential for Labview programmers -- and that's not going to change.


I couldn't disagree more. If you take a really really narrow view, "programmers" don't use LabVIEW. However, engineers do. About half of the electrical, mechanical and controls engineers I work with know and use LabVIEW to various degrees.

"I do not want her to be a LabVIEW programmer." directly implies a very narrow job focus. I use 4 different languages for my day job, and I couldn't do my job well if you took away any single one of them.

C is better than LabVIEW in the same way that a hammer is better than a screwdriver.

I took a course in college in which I learned a new programming language every 2 to 4 weeks. It really opened a lot of doors for me.

[Alan Anderson]

Go to monster.com:
search for -- "software engineer" labview. (26 over the last 60 days)
search for -- "software engineer" c++. (1010 over the last 60 days)

That just shows that people think it takes a "software engineer" to program in C++. LabVIEW is done by people other than software engineers.

While LabVIEW is certainly "great for quickly putting together a UI", once you get the hang of using a dataflow language, it's just as great for general-purpose embedded computing tasks. Exactly the sort of thing that C++ is good for.

[Greg McKaskle]

NI's expectation is to supply both C/C++ and LV for a number of years to come. I don't see any indications of anyone pulling out, and I only expect the documentation and FRC specific elements to get better and easier.

As for the inevitable tool comparison, in my opinion WR and LV are both tools useful for engineering focused problem solving. There are many other tools in use too -- from CAD to mathematical techniques to precisely communicating technical information. I think experience practicing with these tools in an immersive environment like FRC offers a huge advantage towards deciding what sort of path to take after high school. As good as that experience is, it is just a taste, and I still think that the best benefit will be in learning, practicing, and appreciating the many roles -- the teamwork needed to build the robot. Experience in any particular tool tends to have a pretty short shelf life.

And I don't want to knock NI, but the reality is that there's very limited job market potential for Labview programmers -- and that's not going to change.

From Bureau of Labor Statistics --
Mathematicians held about 3,000 jobs in 2006.
From that it might follow that math isn't important because there isn't a good job market for mathematicians. This is of course a bad conclusion to draw.

My point is that the typical LV user wouldn't list their title as a LV programmer. They are a technician, engineer, scientist, or researcher doing some task, and the computer and LV are a tool they use to get their job done. Some jobs naturally call for specialization, others become common tasks such that the original job all but disappears as everyone learns the skill. Computers have evolved so that they are no longer back room devices with specialists keeping them humming. If computer languages evolve the right way, programming will follow a similar path. NI's goal is to provide tools to the engineering masses rather than the specialist?

Greg McKaskle

[gvarndell]

I couldn't disagree more. If you take a really really narrow view, "programmers" don't use LabVIEW. However, engineers do. About half of the electrical, mechanical and controls engineers I work with know and use LabVIEW to various degrees.

I'm not sure how this applies to my assertion that Labview programmers are not in great demand. Whether or not Labview is a useful tool -- in certain situations, for use by non-software engineers -- is not under debate.

My point was, if involvement in FIRST is only going to expose my daughter to Labview over the next 3+ years, I'm having second thoughts.
By the time she goes to college, I want my daughter to be capable of developing robot control software that would be able to sense an object hurtling toward it and decide whether to take evasive action or catch the object -- oh, and to actually do one or the other before the object smashes into it or flies by.

[Greg McKaskle]

My point was, if involvement in FIRST is only going to expose my daughter to Labview over the next 3+ years, I'm having second thoughts.

I don't think there is any risk of that.

By the time she goes to college, I want my daughter to be capable of developing robot control software that would be able to sense an object hurtling toward it and decide whether to take evasive action or catch the object -- oh, and to actually do one or the other before the object smashes into it or flies by.

Oh, well if that is all ...

Seriously though, this goes so far beyond software engineering. It is cutting edge vision processing and robotics. It sounds a bit like RoboCup actually, not a high school sport. I'm not sure all of the CS languages used there, but I know Darwin runs LV.

Greg McKaskle

[Alex_2487]

i am the only perogrammer on my team and i didnt't have any c or c++ experience but i found it much easier to use windriver then labview. The main reason for this is i tohught windriver was just eaiser to understand .the only thing i wish they would have been more exapmles and a better manual.

[dss]

Yes. I'm very content and I enjoy the vi-mode editor.

[xtreampb]

I am the only programmer on the team, and they had to out-source to get me. I live in a diffrent county, so i live 30 min from where everything is going on at while everyone else lives about 5 min away. there were 2 other people signed up on the team to be programmers as well but they had no experience in any language. I have 3 books on C++ and i told them to look at it and i gave them the following link:
http://www.dreamincode.net/
but they never showed up again after the first meeting. My 'mentor' is some-what familiar in labview, so to test the robot while i wasn't able to attend the meetings he would produce code to test individual peices. I do not like GUI development. i beleive that there is more power and controll in hard coding your programs. I have only used the visual studio's IDE. the only other IDE that i have ever used (until this project) is Dev++ from bloodshed. and what is the vi-mode editor. I havn't figured that out ???

[gvarndell]

what is the vi-mode editor. I havn't figured that out ???

'vi' is an editor.

http://en.wikipedia.org/wiki/Vi

The editor in Wind River Workbench has a vi compatible mode.
It also has an emacs compatible mode.

[Analog]

Yes, it is better than labview.

[xtreampb]

'vi' is an editor.

http://en.wikipedia.org/wiki/Vi

The editor in Wind River Workbench has a vi compatible mode.
It also has an emacs compatible mode.

this didn't help me at all. What i got from the wiki is that VI is a fancy text editor??? do you have any more links?

[EricVanWyk]

this didn't help me at all. What i got from the wiki is that VI is a fancy text editor??? do you have any more links?

vi and emacs are "fancy" text editors that have a bunch of features that make them more usable by people familiar with them. Steeper learning curve, but much more productivity.

VI compatibility mode means that windriver emulates that interface. This allows someone who is used to VI to be more productive.

There is a bit of a holy war as to which is better (emacs or vi), it simply boils down to a matter of preference.

[R.C.]

All and All guys I would like to thank NI for doing a great job. Atleast a company stepped up and created a platform for FIRST. I like both platforms , NI Crio and IFI. As time goes on, NI will make learning easier and I hope to see this platform stay for years to come.

-rc

[gvarndell]

this didn't help me at all. What i got from the wiki is that VI is a fancy text editor??? do you have any more links?

You asked what vi mode was.
I had assumed that you might be confused by 'vi', since it's also a Labview term.
My only goal was to help you understand that 'vi mode' has nothing to do with Labview 'virtual instruments'.

Why would someone feel strongly enough about a 'fancy text editor' that they would mention it as a feature (when there are so many other features to mention)?
I can only guess it's because, historically, GUI IDE software development tools have come with a bare minimum editor that simply didn't meet the needs of programmers.
If a coder has to go outside the GUI to edit his/her code, then the IDE is doomed.
I've been using Vi for 25 years, so the inclusion of a Vi mode made Workbench the first IDE I could use for a project life cycle -- design to debug to maintenance.

As for more links, try this one.
http://www.vim.org/download.php
Download VIM for windows and try it.

[gvarndell]

All and All guys I would like to thank NI for doing a great job. Atleast a company stepped up and created a platform for FIRST. I like both platforms , NI Crio and IFI. As time goes on, NI will make learning easier and I hope to see this platform stay for years to come.

-rc

National Instruments and Wind River both deserve our gratitude for their support and sponsorship.

This thread, which I started, has taken some curious twists and turns.
I guess some people thought I was trying ignite a religious war to denigrate NI.
Your post looks like a perfect opportunity for me to set it straight.

I am new to FRC, my daughter just entered high school this year.
When I learned that FRC would be using a 32-bit PowerPC controller this year, I was thrilled.
When I learned that Wind River was providing Work Bench, I was ecstatic.

Please read my original post.
I don't think I asked for anybody to post that they hate Labview.
I just wanted to hear from teams that were using WRWB and maybe a few comments as to why.

FRC requires an enormous investment of time and energy -- for students and their parents.
I was trying to estimate the 'bang for the buck' on that investment.
I can teach my daughter to be a software engineer without FRC.

[Alexa Stott]

Team 25 used WindRiver for all our programming. It was a huge pain to set it up, but far less confusing than LabView. We had a friend from another team come and show us how to do a few things in LV. I've been a programmer for my team for the past 4 years, and I could barely make any sense of his "code."

A few gripes about WindRiver:
1. The setup is excruciatingly long, especially when using school-provided equipment.
2. The manual has more blank pages than useful ones.
3. WindRiver is "buggy" (not sure that's the right word). Some things like having to restart WV when it's not creating a .out file is really just irritating.

Overall, it's better than LabView, but it seems like someone took Eclipse, took away all its useful features, and sent it out to us.

[Mike AA]

One thing I am looking at better with Wind River than Labview, labview (which our robot is currently programmed in) takes a LONG time to build and load to the robot. I have heard wind river takes much less.

Now I have a question, after finding the default code "simple template" what window do I find the code I need to edit? I did code in C last year using the program we had (cant remember now) so I have a good grasp on the context. I loaded the simple template but only found about 20 lines of code in the top center frame but I dont see where any values?

-Mike AA

[Alexa Stott]

One thing I am looking at better with Wind River than Labview, labview (which our robot is currently programmed in) takes a LONG time to build and load to the robot. I have heard wind river takes much less.

Now I have a question, after finding the default code "simple template" what window do I find the code I need to edit? I did code in C last year using the program we had (cant remember now) so I have a good grasp on the context. I loaded the simple template but only found about 20 lines of code in the top center frame but I dont see where any values?

-Mike AA

Could you be a bit more specific about what it is you're exactly looking for?

The SimpleTemplate simply gives you declarations for 2 joysticks and your drive motors using USB 1&2 and pwm 1&2, respectively. It also gives you a basic auto mode and joystick control in teleop (I believe tank drive, but don't quote me on that).

[Mike AA]

Could you be a bit more specific about what it is you're exactly looking for?

The SimpleTemplate simply gives you declarations for 2 joysticks and your drive motors using USB 1&2 and pwm 1&2, respectively. It also gives you a basic auto mode and joystick control in teleop (I believe tank drive, but don't quote me on that).

I actually found what I was looking for in another example. The layout is slightly different than what I am used to but I will hopefully make it work. I have 14days to get it to work with my demo bot setup, it only took me 5 days to learn labview....

[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...:D ).

[EricVanWyk]

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...:D ).

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 :mad:

I personally don't like programming with pictures :\

[Alan Anderson]

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]

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 (http://thinktank.wpi.edu/article/144), 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.


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


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]

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]

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/index.php/2009/03/14/wpilib-test-harness-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 :mad: (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++...