Why Windriver?

[davidalln]

@sjspry I think you misunderstood the purpose of my post (although perhaps I was not clear, my writing tends to be long-winded and confusing). I wrote it in direct response to davidthefat's most recent post, in which he seemed concerned that FIRST has limited his ability to immerse himself in the categories of Computer Science he finds most interesting. I was questioning what this had to do with the closed source/open source argument, and offered my own insights on how to use the tools FIRST gives to study the lower levels of computers.

It's funny that you mentioned the camera drawing, because I implemented something similar over the summer. I'm confused with how much trouble you had getting the JPEG image. I was able to find the solution fairly quickly. To do so, I looked at the WPILib C++ library for the Axis Camera (an open source library that can easily be browsed on FIRST Forge), and saw that all it did was use vxWorks's socket library to pool the server set up on the Axis Camera and stream the JPEG into a buffer which gets sent to the DS. Now, editing the image is a different problem, but there are plenty of open source drawing libraries that can assist in that. I've found that, in this certain instance, the openness of FIRST has allowed me to solve the problem without any interference or barriers.

In response to your comments on optimization, yes, it is written at the highest level. However, you need a deep understanding of how vxWorks processes and prioritizes all the work necessary to complete the program to successfully create the fastest code possible. There are plenty of ways you can implement this, as well as multithreading, in FIRST again utilizing the power of the well documented vxWorks operating itself. Just because its not laid out nicely in WPILib or LabVIEW VIs doesn't mean its blocked off from accessing and impossible to implement.

I disagree with your comments on the OS. Personally, I don't find it unnecessarily limiting that you cannot openly access every part of the file system on the cRIO. FIRST needs to ensure some level of consistency across teams for competitions and field connectivity to run smoothly. There is absolutely no need to access this level of the cRIO and, although I would certainly find it interesting to dissect the internals of the field management system, it is for the greater good of the competition that this is left secure.

(the compiler statement was in response to his wish to work on and study compilers, to which I pointed out that FIRST uses an open source compiler if he wants to see how the inner workings of how one works).

And, if the opportunities FIRST has presented to you cannot satisfy what you're looking for, the option to place a computer on your robot this year can fulfill that gap. Look into using a Gumstix minicomputer (which by default has a flavor of ARM Linux installed), or building your own, to outsource some of your robot control system. Here you can get literally as low level as you want, even writing in pure machine code if you truly desire. Send data through ethernet back to the cRIO, and make your robot do sick things.

tl;dr "FIRST is more open than you think"

[sjspry]

Originally Posted by davidalln

I disagree with your comments on the OS. Personally, I don't find it unnecessarily limiting that you cannot openly access every part of the file system on the cRIO. FIRST needs to ensure some level of consistency across teams for competitions and field connectivity to run smoothly. There is absolutely no need to access this level of the cRIO and, although I would certainly find it interesting to dissect the internals of the field management system, it is for the greater good of the competition that this is left secure.

I see where you're coming from, but they don't actually mandate you keep the VxWorks software on the cRIO, ergo they aren't really concerned in this respect. As long as you use the official "Driver Station" software, you can have your robot and hardware do whatever. I'm sure the system is already open enough you could spoof commands if you wanted, last year we had our router out for testing purposes and it was sucking robots into it until they asked us to turn it off. Just add some ARP spoofing, and presto, they wouldn't notice.

Thanks for the tips btw. What I ended up doing before was hitting <ip>/axis-cgi/jpg/image.cgi?resolution=320x240 a few times a second. Way more responsive than the premade dash.


@Greg I skipped writing a wrapper library for several reasons, the main one being I wished to write my own recognition routines (I'm sure NIVision is good at what it does, but it could turn out problematic based on the differing circumstances of our testing area and the playing field. My idea was something much simpler with just some blob detecting, where I just need to find a color range for, example, the pole or the tape.). After realizing I wouldn't be able to do anything quickly within Java, I just ended up moving all the recognition code to the computer so I could stick with Java. Much easier in my opinion than having to write everything in C++. The libraries on the cRIO are so limited I'd much rather be doing it on the computer anyway, and I'll be using Java simply because of the large standard library.

[Greg McKaskle]

they don't actually mandate you keep the VxWorks software on the cRIO

Actually, it is required. You can do whatever you want for the offseason, but for FIRST events, the FPGA image and communications code on the cRIO are essentially agents of the FMS, ensuring that the robot is controllable by the field.

As for the dashboard, all of the camera users are using the cgi requests to the camera. There is a bmp, a jpg, and an mjpg that you can use. The default dashboard goes through the cRIO, but if you move the camera, your laptop can directly talk to the camera.

If you'd rather use the laptop to learn about image processing, that sounds like a fine initial approach. But it would be a good idea to learn how to use other people's libraries, like NIVision -- Color conversions, color thresholds, blob measurements, all in there. Additionally, when you find things that aren't in there, the libraries can be extended. Deciding that you have to do everything over again, in the language you choose can be a tough requirement on any project. But if you are making progress and helping the team build a better robot, power to you, let me know if you have any questions.

Greg McKaskle