Re: How does your team incorporate engineering units?
 

Thanks for giving your reasons. I'll try to give a brief comment on each of these.

Code is flawed ... I don't directly contribute to the C++ or Java versions, but http://firstforge.wpi.edu is where the bug tracking takes place. Opinions on how the libs are bloated may not make a good bug report, but issues such as you listed sound like good bug reports. Do you know if the detailed issues are captured?

Low-Level is undocumented ... The low-level interface is machine generated and as pointed out on the forum, it can change if a new FPGA image is built, if HW changes, etc. This undocumented interface is a pretty straightforward peek/poke interface with some locking and indexing built in. It was not intended that it be used directly or that teams would develop their own language support without being on the control system team. Do you have specific questions that are keeping you from making progress?

Tool chain ... The tool chain for C++ is indeed out of date and it is intended for professionals or well-mentored teams. Both the Java and LabVIEW tools are modern and simpler. The new control system will offer more modern tools for C++. And of course, this is also a matter of opinion. Arduino is simple, LEGO is simple, but what level of challenge is appropriate for the FRC challenge? I think it is important that the students get exposed to real engineering, and that isn't always simple. That is where the mentors come in.

Problems ... The issue listed sounded like it was unique to vxWorks tools. It isn't something that can be fixed by NI or WPI.

Please don't take my comments the wrong way. I agree that the libraries should put the majority of emphasis on the fundamentals of getting the robot to do what was intended. I'm not itching to implement units, but if they are a significant gap that teams struggle with, the LV solution is relatively easy to implement -- by teams or by NI. I'm not sure they are needed, thus the question.

Thanks for the feedback.
Greg McKaskle

Re: How does your team incorporate engineering units?
 

Actually, I confess. I was the person who broke the CPU plot, but it was broken during the beta test, not after. And the break was due to extensive changes in what was being logged at the DS. Logging changes were also the reason the log file viewer wasn't updated at kickoff -- it wasn't ready, so we shipped the previous years until the updated version was ready. This wasn't an oversight, but a conscious decision. It was a trade-off caused by what took place on Einstein months before.

I apologize for the mistakes, but I'd hope that you didn't characterize them as "stupid" to students you mentor. Tools and products around you will include mistakes, and having discussions with the students about the issues is great. But mistakes are often caused by factors other than stupid.

Greg McKaskle

Re: How does your team incorporate engineering units?
 

Sorry if my post sounded kind of harsh. I didn't mean it that way. The fact that the CPU plot was broke during the beta test is news to me, and don't worry, by "stupid" mistake, I'm talking about an issue that could be easily solved easily (which it was, in the first update), rather than something that was actually "stupid". I understand that a lot of the work done is by volunteers, and demanding perfection isn't right. I know that you're the LabVIEW guy, and I've only used LV for one year, but my experiences with the libraries were that they were significantly more "polished" and documented. I could go through all the different subVI's for the motor set vi, and I could understand every portion of it, even without much LV experience.

The C++/Java libraries are different. Large portions are written quite well, and implement object oriented programming concepts quite well. Other portions are a little less great. For instance, whenever you use one of the "canned" PID controllers, it automatically puts it in a new thread and updates the output with this thread. While it's really easy to get insight into why some things are the way they are with LabVIEW (talking to you), it's a little bit trickier getting a bug fixed for java. Many of the little frustrating things (like the debugger) are reported, but ignored year after year.

If the LabVIEW libraries work (which I think they do), then, by all means, the unit feature would be awesome.

As for Java/C++, there's important missing documentation, so I think that teams would benefit from improved help rather than a new feature.

Re: How does your team incorporate engineering units?
 

I haven't submitted any bug reports to WPIlib myself, but one of the other mentors on my team has submitted six. Three of them say that they've been fixed in the next release, but their fixes aren't available to us since we don't have access to their private repository. The other three appear not to have been touched; they are still listed as unassigned in the bug tracker. What do you mean by captured?

As far as the low-level interface, the big question I have is what is the minimum set of calls that I must make to have the robot operate during a match and when must they be called? I would assume that at least some of the things in the robot template could be omitted, such as reporting the programming language. But I don't actually know this and it might be that the FMS will lock out a robot that omits that step. I know that if you screw up the calls that update the virtual LCD text you can make the robot become disabled.

Does Labview also use all of the routines that appear in "FRCComm.h" underneath or does it have its own set of communications primitives?

This is good to know and I hadn't heard this before. I'm glad to hear this is in the works even if it won't be ready for the 2014 season.

Who would be the right person to bother about the code downloading problem? This occurs when you hit the menu item "FIRST->Deploy". Who implemented the customizations of WindRiver Workbench? Do you know whether they have a bug tracker?

Sorry if all my questions are outside of your department.

Re: How does your team incorporate engineering units?
 

By captured, I simply meant recorded. If you do not have access to the stable builds, then you may be able to check with a beta team.

The calls into FRC_Network_Communications for things like language are not required, but they are helpful so that FIRST and the controls team know what resources are being used. We may still need to poll, like this one on units, but we will have hard data on how many teams use various features that are present and being tracked.

Do you have a reproducible way to get the LCD to mess things up? That info never leaves the DS, so it would probably just be a bug that went unidentified. LV does use the same FRC Comm calls, but it uses a different mechanism for doing peek and poke to the FPGA. The purple nodes that it uses predate the FRC project and ChipObjects were written to allow C++ and later Java to more easily interact with the FRC register set that is compiled into the bit file.

If you think the deployment issue has to do with the project extensions and settings, I'd probably put them on the FIRSTForge site. The vxWorks tools are dated and require that they are installed with no spaces in the name. If the path limitation is the issue, then it is inherent in the WindRiver tools. They may have fixed it in a newer version of workbench, but NI has decided against migrating to newer versions.

No need to apologize. I understand how frustrating it can be when you don't see the sort of progress you desire and instead see energy being put elsewhere. I was just trying to make us all more productive.

Greg McKaskle

Re: How does your team incorporate engineering units?
 

The setup for the LCD problem is somewhat involved. We have port of the C++ version of WPIlib to Unix and when the calls to update LCD information are switched from being a no-op to actually sending information it causes the driver station to think that the robot is dead and put it into disable mode. Looking at a wireshark trace doesn't show any obvious difference between the output given by the real robot and the simulated one. This behavior is probably due to some problem in our code. We're probably done something wrong, like doing operations in an unexpected order or with unexpected timings, but we don't really know what the driver station requires since the protocol is undocumented.

So anyway, I don't know whether the driver station is working to spec since I don't have the spec for what it's supposed to do.

I will look into the FIRSTForge site for the deployment issue but I do know that it is neither spaces in the name nor path length.

Re: How does your team incorporate engineering units?
 

If you give me the program that reproduces the issue, I can help identify what is going on.

It is possible that the FRC_Communications and the DS don't agree on the exact location of some LCD info, and it may just be the case that nobody uses it in the way that exposes this issue.

Does it have to be a linux version to fail? It would be easier for me if you could either give an access pattern that I can program, or give me a cRIO program I can run.

PM if you need to get email or ftp details. And thanks in advance for reporting the bug and helping to get it squashed.

Greg McKaskle