Thread: Why Windriver?
View Single Post
  #21   Spotlight this post!  
Unread 21-01-2011, 02:45
davidalln's Avatar
davidalln davidalln is offline
World's Worst Coder
AKA: David Allen
FRC #2415 (The Westminster Wiredcats)
Team Role: Programmer
 
Join Date: Mar 2009
Rookie Year: 2008
Location: Atlanta, GA
Posts: 108
davidalln is on a distinguished road
Send a message via AIM to davidalln
Re: Why Windriver?

@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"
__________________
SANTOSH ANDREW DECKER RICK WYNNIE SEAN DEREK MATT
(alamo (semis), p'tree (CHAMPS!), nc (CHAMPS!), newton (quarters))


Best four years of my life. Thanks to everyone who made it happen.