Anyone interested in a Linux-based robot solution?

[Alex.Norton]

Originally Posted by taichichuan

Yeah, that was my thought as well. Via an O/S specific header and a glue library, you could make the WPILib fairly OS/platform agnostic. You'd probably have to watch out for the big endian/little endian thing, but that could be dealt with ala the way the network code handles it. If you define BIG_ENDIAN it does one thing, LITTLE_ENDIAN does another. However, I am concerned that we keep things to something that can be tested and verified to work for safety's sake if not for our own sanity.

This is why I specifically quotes Qt as a possibility because all that needs to be done is have the correct version to link to and it will work. No need to do ANY platform specific stuff in the code. big/little endian isn't a problem as long as the correct version of Qt was compiled using the compilers on that machine. That is the one problem, the person doing the development would need to have Qt downloaded and working on that machine.

I'm also sure that there are other platform independent libraries that could be used, I just like Qt because I've been working in it for the past 6 months. It would be nice though to rewrite the code once, and then if a new platform needs to be added, all you have to do is find the version of whatever library you use that works on that platform.

EDIT: My philosophy: for this, any platform specific code that I need to develop is too much.

--Alex

[gvarndell]

Mike, sent you a PM about this thread....

[oddjob]

Has anyone considered contributing to this:

WPILib test harness

For most all teams, there is one or maybe two cRIO's and limited access to the hardware in the final weeks as the robot is approaching fully constructed. Access to a virtual cRIO platform would be very useful.

Investigating cheaper hardware options, there's nothing bad about that.

If the code runs on Windows, Linux or OS/2 or whatever, I couldn't care less as long as there is the C++/Labview/Java programmers environment and robot comms interface.

This year "no robot code" and "no camera images" consumed a lot of forum bandwidth. Imagine what will happen if the pandoras box is opened and the teams have access to all the low level real time OS hooks. How will that be supported? FIRST have to ensure the integrity of all the robot code for field competitions. How will they do that? Be careful what you are trying to accomplish. The FIRST programming environment is locked down for a reason.

[gvarndell]

Originally Posted by oddjob

This year "no robot code" and "no camera images" consumed a lot of forum bandwidth. Imagine what will happen if the pandoras box is opened and the teams have access to all the low level real time OS hooks. How will that be supported? FIRST have to ensure the integrity of all the robot code for field competitions. How will they do that? Be careful what you are trying to accomplish. The FIRST programming environment is locked down for a reason.

We're looking for a way to teach self-help.
Locked down black boxes are great when they are absolutely bullet-proof and well documented.
When they are more like bullet-riddled and just plain obtuse, they are a quagmire.
The question of whether or not FIRST would approve an alternate controller, or allow running an alternate OS on the cRIO or an alternate controller, is absolutely an important question.
But the scarcity of hardware really kinks any efforts at hands-on teaching.

[Robototes2412]

I'm thinking about making a nintendo-ds mediated system using an adruino and a custom Slot-2 (gba slot) insert. What do you guys think?

[jhersh]

Originally Posted by gvarndell

Locked down black boxes are great when they are absolutely bullet-proof and well documented.
When they are more like bullet-riddled and just plain obtuse, they are a quagmire.

Which one would you classify the FRC control system as?

[gvarndell]

Originally Posted by jhersh

Which one would you classify the FRC control system as?

A quagmire to be honest.
Not the hardware, the apparently wide-spread perception that the cRio is too slow has little to do with reality.
And this has nothing to do with LabView -- I'm staying out of that debate from now on.
I'm perfectly happy with the cRio and vxWorks.
But the (C++) software is too brittle; and too opaque to diagnose and trouble-shoot.
I'm not a big fan of Linux for embedded systems, but I think Mike has started something here that has value.
The kids who want to learn software are just learning shotgun diagnostics.
They should be taught more methodical and analytical approaches.
I hope you are not offended, I am blunt when I think bluntness is called for.
I would be happy to take this discussion to email if you think that's worthwhile -- please PM me if you do.

[taichichuan]

Originally Posted by jhersh

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

[CoachPoore]

A solution (vxWorks/Linux/...) that enabled the robot "application" to run as user code would be a good improvement. Having to run our code as a VxWorks kernel module is not ideal and makes a lot of bugs much harder to track down.

[jhersh]

Originally Posted by taichichuan

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.

That is a major goal, but we don't want it to be obtuse... and I don't believe those two must be mutually exclusive. If you have ideas for ways to make it better, please suggest them. Better yet, create patches that demonstrate what you have in mind and it'll be more likely to change for the better.

Originally Posted by taichichuan

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.

I can appreciate that.

Originally Posted by taichichuan

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.

I look forward to some specific suggestions for improvements. The WPILib tracker is open for business!

-Joe

[virtuald]

Originally Posted by oddjob

Has anyone considered contributing to this:

WPILib test harness

For most all teams, there is one or maybe two cRIO's and limited access to the hardware in the final weeks as the robot is approaching fully constructed. Access to a virtual cRIO platform would be very useful.

Investigating cheaper hardware options, there's nothing bad about that.

If the code runs on Windows, Linux or OS/2 or whatever, I couldn't care less as long as there is the C++/Labview/Java programmers environment and robot comms interface.

As the original author of the WPILib Test Harness, a lot of the stuff that is being discussed in this thread was my motivation for writing it originally. In particular, I was highly annoyed that I couldn't do any code development outside of the cRio. However, I haven't had the time to actually do any work on it this season -- but maybe this summer or something.

The WPILib Test Harness is currently C++ specific. I thought I saw someone mention that the Java code can be ran outside of the cRio, but don't quote me on that. Running LabVIEW outside of the cRio without NI support would be an exercise in futility.

One of the lessons learned from working on this, was that WPILib is *very* platform specific underneath the hood. Trying to port it in its existing state without some major rewrites would be very time consuming.

As far as OS primitives and multithreading, I've elected to use the boost threading libraries for that. It's a bit more than what some people like using, but it works pretty well and is quite cross-platform. It would be really nice to see FRC ship boost by default with the development environment.. but of course, there are a lot of caveats there.

[mikets]

I am relatively new to Robotics and this forum. This is my first year to be involved in both FTC and FRC. I can appreciate the argument about not being able to develop and debug code without the expensive cRIO setup. But since I was also involved in FTC that uses the Lego Mindstorms, I was trying to develop an abstraction layer so that both FTC and FRC code can be based on the same library. This means that I can experiment and debug different algorithms without caring too much about whether it is cRIO or Mindstorms. I am starting to develop a library to achieve that goal. I am very far from the goal because of the differences between the platforms plus the fact that FTC doesn't support C++. Nevertheless, algorithm is algorithm and should be independent of programming language anyway. So I am planning to use the Mindstorm to develop the library and port it as best as I could to the cRIO. I am heavily using macros to hide the platform differences. I am not quite there in terms of source compatibility but that is my goal eventually.
It would make it easier if Windriver/WPILib also supports Mindstorms. This would greatly reduce cost in learning and experimenting with code. One can easily build a lego prototype to try something, migrate it to the FTC setup and eventually to the cRIO.

[AustinSchuh]

Originally Posted by mikets

I am very far from the goal because of the differences between the platforms plus the fact that FTC doesn't support C++..

I haven't done anything with the FTC platform, but I do know that you can load alternative OSes onto Mindstorms robots. The NXT platform will run a RTOS that you can target with GCC. Which lets you develop C and C++ code for it.

http://lejos-osek.sourceforge.net/whatislejososek.htm

[Gdeaver]

I'll throw this out there. It has already been noted that with the 2can box a basic drive train only robot can be created. Why not serialize the whole thing and take the heavy duty expensive brain and FPGA out of the robot? Isn't this the strategy Microsoft was pushing with the robotics studio environment? In other words, we would use a laptop with what ever power a team felt necessary as the main brain. The lap top would take user input through the USB ports,and do all of the processing. Command and status packets would be transmitted over wifi as we have now. The 2can can be expanded and maybe have a pair of can ports and some usb. There are usb servo boards with 20 pwm on them. Next add a usb or can solenoid driver board, a digital io board and an analog board. Other than maybe having problems with zillion cpr encoders, everything that we have now is there. In other words get everything back to a PC and do the crunching there. Now you have an Intel/AMD/Nvida platform to host the operating system and do the processing. The cost of the individual boards would be well under 200$. The cost of the 2can would go up . There are companies providing boards like this for the Microsoft robotics studio and .net frame work already.

[ajd]

Originally Posted by Gdeaver

I'll throw this out there. It has already been noted that with the 2can box a basic drive train only robot can be created. Why not serialize the whole thing and take the heavy duty expensive brain and FPGA out of the robot? Isn't this the strategy Microsoft was pushing with the robotics studio environment? In other words, we would use a laptop with what ever power a team felt necessary as the main brain. The lap top would take user input through the USB ports,and do all of the processing. Command and status packets would be transmitted over wifi as we have now. The 2can can be expanded and maybe have a pair of can ports and some usb. There are usb servo boards with 20 pwm on them. Next add a usb or can solenoid driver board, a digital io board and an analog board. Other than maybe having problems with zillion cpr encoders, everything that we have now is there. In other words get everything back to a PC and do the crunching there. Now you have an Intel/AMD/Nvida platform to host the operating system and do the processing. The cost of the individual boards would be well under 200$. The cost of the 2can would go up . There are companies providing boards like this for the Microsoft robotics studio and .net frame work already.

(I really don't know the answer to this question.) Could that have any impacts on processing speed if all sensor inputs needed to go through the wireless? I'm specifically thinking of stuff like tight feedback loops. (I know you can plug encoders directly into the Jaguars, so I guess that wouldn't be a problem, but it seems like you might need more complicated feedback loops that wouldn't be accounted for by that.)