View Single Post
  #23   Spotlight this post!  
Unread 26-04-2010, 16:04
taichichuan's Avatar
taichichuan taichichuan is offline
Software Mentor
AKA: Mike Anderson
FRC #0116 (Epsilon Delta)
Team Role: Mentor
 
Join Date: Feb 2010
Rookie Year: 2010
Location: Herndon, VA
Posts: 333
taichichuan has much to be proud oftaichichuan has much to be proud oftaichichuan has much to be proud oftaichichuan has much to be proud oftaichichuan has much to be proud oftaichichuan has much to be proud oftaichichuan has much to be proud oftaichichuan has much to be proud oftaichichuan has much to be proud oftaichichuan has much to be proud of
Send a message via AIM to taichichuan
Re: Anyone interested in a Linux-based robot solution?

Quote:
Originally Posted by jhersh View Post
Which one would you classify the FRC control system as?
Well, I'm afraid I'd also have to come down on the side of quagmire. As someone who's been working with VxWorks for over 20 years, I can say that a 400 MHz PPC is more than fast enough for what we're doing with FIRST. Heck, I've flown real airplanes with less CPU horsepower at my disposal.

For example, I created a class that uses an IR Scanner and a servo to scan the field for objects of a given size. In spite of my belief that I could do it in the native O/S much faster and simpler, I opted to work within the framework of the WPILib. It took me almost two days to puzzle out how to create and control a thread using the framework. And, I only figured it out by dissecting the code in SourceNavigator and knowing the VxWorks API so I knew what to look for. Obscure would be an understatement, IMHO.

I get the goal of the WPILib. Try to make it easier for teams to be successful at getting something on the field. That's a laudable goal and for the most part, between Labview and/or the WPILib, it sort of works. There's a lot that could be made less obtuse, but I get it.

What I'm looking for is a way to be able to test and develop code in absence of a cRIO. Something that a school or even an individual can afford more than one or two (or three) of. Even with those teams with 3 cRIOs, one is on last-year's robot. One is on this year's robot for driver training and mechanics checkout and then the last one is scavenged for parts or so hard to schedule time on that the software developers are hard pressed to gain access.

The only reason I suggested Linux and ARM (MIPs, Atom, or whatever) is that the hardware is cheap and plentiful and the O/S is free. I want to encourage kids to explore the software beyond the build season and cost is a major factor. I also want to teach the kids good embedded software practice (like no dynamic memory allocation at run time) and to be able to think in parallel with threads. We live in a multi-core world now even in the embedded space. Processors line the ARM Cortex A9 are just the tip of the iceberg in this realm.

I feel that what FIRST has put together with the software system certainly hits a significant goal of allowing a team with minimal software background field a robot. I just want to take those ideas a little further, make them more accessible, less magic and help us grow some talented software engineers.

Mike