Anyone interested in a Linux-based robot solution?

[taichichuan]

Greetings fellow robot fans,

I'm just throwing an idea out here. Are any of you interested in a Linux version of WPILib? I see several companies are starting to produce ARM-based boards that have all of the DIOs and AIs that you would need for a robot e.g.:

http://www.vexforum.com/wiki/index.p...icrocontroller
http://www.phidgets.com/products.php...roduct_id=1070

These are *way* cheaper than the NI cRIO platform. Don't get me wrong, I like the cRIO, but for cash-strapped school systems, the expense of the cRIO can be daunting. I actually looked into NI's robot starter kit as well. But, I found that the multi several $K price tag to keep the software licenses running after the 6 month software timeout to be way too expensive even with the substantial educational discount.

Before you panic about sponsors, both WRS and NI support Linux versions of their development environments as well as Linux target code. An the development environments can run on Linux or Windows and still cross-target code to Linux. I'm not looking to alienate anyone here, just looking into an alternative that can help lower costs and provide for a little more flexibility.

In addition, for those who are really interested, you could then support Python, Java, C/C++, Perl (shell scripts !?!?!) etc. with multi-tasking and have memory protection that would keep bad pointers from crashing the system as easily as it can be done w/ the flat memory model of VxWorks. Also, with WRS's Linux and the PREEMPT_RT patch (which WRS includes in their distro), you can get the kind of real-time performance that we would need for FRC. Or, you could build it yourself with something like the OpenEmbedded distro if you were so inclined.

Of course, the WPILib would need to be ported. That wouldn't be trivial. But, it's certainly doable in a couple of months based on my examination of the code. Certainly, with the memory protection of the kernel and key data structures that Linux provides, you could certainly argue that a robot based on a protected-mode O/S like Linux would be "safer". Also, as someone who works in the embedded space and has for 30+ years, I can tell you that Linux is a serious contender for embedded systems (e.g., Android, WebOS, Nokia's Maemo, etc.). Having embedded Linux experience would be a real plus for the students.

This isn't intended to replace the existing hardware/software combinations -- just provide a lower-cost alternative. One that would allow the students to continue to develop and test code in the absence of the main robot or after the build season.

So, what are your opinions? Would you be interested in a low-cost Linux-based solution? I'm sure that I've not taken into account all of the political ramifications, but let's worry about the technical challenge first.

Any thoughts?

Mike

[whytheheckme]

I'm a little bit confused. Are you talking about porting WPILib to a different hardware controller?

Are any of you interested in a Linux version of WPILib?

Linux isn't a programming language... WPILib isn't Windows specific
Perhaps I'm just missing something here.

Jacob

[taichichuan]

Originally Posted by whytheheckme

I'm a little bit confused. Are you talking about porting WPILib to a different hardware controller?



Linux isn't a programming language... WPILib isn't Windows specific
Perhaps I'm just missing something here.

Jacob

Well, actually it's a bit more complicated than that. You are correct in that WPILib is in C++ (among others). However, the library is full of O/S-specific features like VxWorks semaphores, tasking, etc. So, porting WPILib would involve porting to a new operating system (and the POSIX programming model) as well as new controller hardware. Of course, the PPC 5200 found in the cRIO is also well supported by Linux and it's based on a board design that already has a Linux board support package (BSP). So, even the cRIO could be supported.

But, part of the project would be to port to less expensive controller hardware as well. This would enable more experimentation with controls over what is possible with the limited numbers of cRIOs based on the KOP as well as lower the cost of entry.

Fortunately, in the way that Linux works, you could have a C/C++ library and support other languages like Python, Java, etc. via the same mechanisms that are used normally, like Java's JNI, without having to have a version of WPILib for each supported language.

Mike

[gvarndell]

Originally Posted by taichichuan

So, what are your opinions? Would you be interested in a low-cost Linux-based solution?

Mike, I have the deepest respect for you, but NOOOOOOO!
I was really hoping we could reduce the number of 'no robot code' problems next year -- not catapult them off the chart. ;-)

[taichichuan]

Originally Posted by gvarndell

Mike, I have the deepest respect for you, but NOOOOOOO!
I was really hoping we could reduce the number of 'no robot code' problems next year -- not catapult them off the chart. ;-)

Hey George!

I found that a lot of the 'no robot code' problems were because the kids couldn't deal effectively with the "download to a foreign O/S and get it deployed" issues of the FIRST-specific tab in Workbench. Obviously, I'm C++ centric and I can't comment on the issues encountered by the Java or Labview-based teams. But, I'm thinking more along the lines of simply having a SAMBA mount or NFS mount and drag and drop via file manager/Explorer (or via the FIRST tab which was really just an FTP session with a specific target name anyway). It would be a lot easier for folks if they could just see the file system using tools they're already familiar with. Of course, I did it with filezilla and bypassed the FIRST deploy code thing entirely. But, that was because I knew the target O/S pretty well.

Now, I've built hundreds of systems on both O/S platforms over the years. And, I'm finding that many of my customers are having a lot less trouble with Linux because it's more familiar. Please, don't misunderstand. I *like* VxWorks. But, the kids really don't get much time to play with the O/S because it only runs on the one platform. Also, their perception on the O/S is limited because much of what they see is the WPILib, and not the underlying O/S. Maybe if we had a viable copy of the VxWorks simulator with WPILib support, things would be different. What, specifically, are your concerns with Linux?

However, another aspect of this discussion is getting a target that is cheap enough that teams can afford multiple processor boards for work while the robots are in transit or after the build season. Some teams are lucky enough to have multiple cRIOs. But, many teams from cash-strapped school systems can't afford the gear. For example, just the chassis for the cRIO is selling for $475 on EBay. That would buy 3 Beagleboards from Digikey with no additional cost for the development environment. Of course, VxWorks runs on ARM platforms as well. Is there a Beagleboard port?

Also, there are a lot of inexpensive USB robot-oriented interfaces coming out. Using commodity USB cables *might* simplify the wiring and cable runs for rookie teams. I saw our kids spending a lot of time working with crimping tools and soldering irons. Not that that is a bad thing, mind you. I'm just thinking of ways to keep the kids thinking beyond the build season with something they could do at home or schools could do on a budget.

So, this is just positing ideas that could help address some problems that I've seen. And, your concerns are valid. That's part of why I started the thread. To get the concerns out on the table and find out if there's an interest and what the technical issues are.

Thanks for the reply.

Mike

[gvarndell]

Originally Posted by taichichuan

Maybe if we had a viable copy of the VxWorks simulator with WPILib support, things would be different.

Things would have been be very different.
I am terribly disappointed that Wind River withheld vxsim from the FIRST packages.
Even better, far better, would be a virtual cRio that could run the same target binaries as the real hardware.

What, specifically, are your concerns with Linux?

My concerns are not with Linux.
I am concerned that supporting another target OS would spread even thinner the apparently already over-burdened target software development resources being applied to FRC control systems.

[taichichuan]

Originally Posted by gvarndell

Things would have been be very different.
I am terribly disappointed that Wind River withheld vxsim from the FIRST packages.
Even better, far better, would be a virtual cRio that could run the same target binaries as the real hardware.



My concerns are not with Linux.
I am concerned that supporting another target OS would spread even thinner the apparently already over-burdened target software development resources being applied to FRC control systems.

Yes, maybe a QEMU implementation with a virtual set of hardware. I know that WRS uses QEMU for its training classes. However, I think they're doing ARM rather than PPC. I believe QEMU does support a PPC instruction-set simulator, but I'm not sure about a virtual PPC 5200 that could run the FRC binaries. But, something like that would certainly go a long way to giving folks a chance to work with the code without needing the physical cRIO hardware.

As for software development resources, I certainly understand your concerns. However, reworking the WPILib to make it O/S independent might actually be a good thing overall. There are several places where there are good examples in the WPILib already like the "CRITICAL_REGION/END_REGION" code. If they followed that pattern, the O/S-specific code could be limited to a small header file and some glue code.

Personally, I found that the WPILib itself had a significantly steep learning curve. Certainly, the documentation on the theory of operation on WPILib left much to be desired. As someone who has been working in the controls biz as long as I have, I found the WPILib inscrutable in many cases (such as how to create and monitor a thread). Thank goodness I had access to some great mentors on the team who had prior experience that could answer my questions. I'm not sure where that leaves rookie teams.

And, as an example of what you *should* do in real-time control code, WPILib has many examples of how academics and field practice differ. Of course, I'm talking about the C++ code. I can't speak to the Java or Labview code. IMHO, WPILib is a good effort at trying to hide the details. But, the devil is in the details for embedded code.

As I watched the threads here on CD, I began to get the feeling that many teams were simply shotgunning the problems. Without the understanding of what was really going on under the hood in the WPILib, many just seemed to be trying stuff at random. Yes, the WPILib code is available for download. And, believe me, I would have had a hard time understanding much without the sources to go look at. But, I feel that the kids are encouraged to treat the code as a black box and simply accept what it does. We're missing a good teaching moment by not looking under the hood to understand how it works.

So, we come back to the reason I started this thread. The goal is to make the code more accessible by providing a less expensive way to get it into the kid's hands and allow them to play with it, test code, and understand what's going on both during and outside of the build season. I feel that getting a good simulator may be one way to make this happen. But, I also feel that getting the code and interfaces running on a less expensive platform may be another.

Let me emphasize here. These are simply my opinions. They're probably worth what you paid for them ;-) .

Mike

[bear24rw]

I always thought it would be nice to see like a 200Mhz ARM running linux. Programming the robot could be as easy to dragging a file to it over ftp/ssh. you could distribute a cross compliation package out of free open source tools.

then again, i wouldn't mind seeing the old IFI Controller come back (but maybe with AVRs ;p). It seems like the the programming has been much abstracted from the low level stuff. Guess I just miss having lower level hardware access.

[Robototes2412]

actually, if you wnat something like this, check qi hardware, they have a fpga-based robot brain thats a mips openwrt thing. WPILIB would port nicely <3

[AustinSchuh]

I've been browsing for hardware for another robotics project, and thought I'd share some of the stuff I've found.

Have you considered www.fit-pc.com/web/fit-pc2/ as another option for a CPU? I haven't bought one yet, but it's supposed to be able to run off 12 volts unregulated 8-15 volts, and has an Intel Atom CPU in it. And a wireless card built in. I've also heard that OMAP4 (Arm Cortex-A9, dual core) boards will be coming out within a couple months. I'm rather excited about that last one.

Here's a AVR micro-controller that you hook up via USB, and will give you quite a number of analog and digitals. www.pjrc.com/teensy/index.html If I'm reading the website correctly, the best part is that their USB interface on the AVR is done "right", rather than just as a USB->Serial adapter.

As a bit of information, it's actually pretty easy to rip the guts out from the bottom of WPILib and replace it with something else. I was able to get joysticks working, and Victors/Jaguars working by just modifying the DS class for the Joysticks, and implement motor controllers similarly easily (I forget how), before I got distracted and moved on to the next project.

[Robototes2412]

actually, an arduino+DS combination would work pretty well, as shown here: http://www.youtube.com/watch?v=8sp8Is3Nuts

The arduino would be about $29.95, and about another $90 for the ds, a flashcard, a uSD card, and a protosheild for hooking up the robot stuff. The WPI library would have to be ported to the DS, and i don't know about a camera, but it should work, seeing that the DS has built-in wi-fi and all.

[Alex.Norton]

I haven't played with the new robot control system (last robot I worked on was 2007) so I don't know much about WPILib, however from the non hardware side of things, If your going to be rewriting the library to not be platform specific perhaps you should write the platform specific stuff in a platform independent library (only do the work once).

I realize that it adds another library that would be needed for development on any particular machine, but as example http://qt.nokia.com/products is a platform independent C++ library. There are versions for linux, and VsWorks and there are two different opensource licences that it can be used under.

just a thought,
--Alex

[taichichuan]

Originally Posted by Alex.Norton

I haven't played with the new robot control system (last robot I worked on was 2007) so I don't know much about WPILib, however from the non hardware side of things, If your going to be rewriting the library to not be platform specific perhaps you should write the platform specific stuff in a platform independent library (only do the work once).

I realize that it adds another library that would be needed for development on any particular machine, but as example http://qt.nokia.com/products is a platform independent C++ library. There are versions for linux, and VsWorks and there are two different opensource licences that it can be used under.

just a thought,
--Alex

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.

Since we're limited to what the battery can supply, I'd be reluctant to jump on the Atom processor until the generation after next (Medfield?) due to power draw. The current Pineview draw is something like 2 watts compared to the ARM Cortex A8/A9 in the sub 500 milliwatt range.

Of course, using an Intel-based board makes it even easier to develop code for. But, I like the idea of using a cross-compiler because that's a lot of what embedded systems developers do in real life. It's nice to give the kids a taste of how the pros in the industry work.

Mike

[gvarndell]

Originally Posted by taichichuan

Yes, maybe a QEMU implementation with a virtual set of hardware. I know that WRS uses QEMU for its training classes. However, I think they're doing ARM rather than PPC. I believe QEMU does support a PPC instruction-set simulator, but I'm not sure about a virtual PPC 5200 that could run the FRC binaries.

Wind River now has Simics.
You should see an end to QEMU usage very soon.
There is no 5200 model yet.
Needless to say, nobody should hold their breath waiting for it, but it doesn't hurt to hope that Wind River will have one, and let FRC teams use it, next year. (dear santa, before build season would be swell)

And, as an example of what you *should* do in real-time control code, WPILib has many examples of how academics and field practice differ.

<biting my tongue, real hard> uh, yeah, you could say that....

So, we come back to the reason I started this thread. The goal is to make the code more accessible by providing a less expensive way to get it into the kid's hands and allow them to play with it, test code, and understand what's going on both during and outside of the build season. I feel that getting a good simulator may be one way to make this happen. But, I also feel that getting the code and interfaces running on a less expensive platform may be another.

Excellent goal.
I think the technical obstacles are negligible compared to 'other' problems though. OTOH, even if FIRST didn't officially approve these cheapo systems for competition, they could indeed be great learning platforms.
You've got me thinking now, I'll be watching where this thread goes.

[davidthefat]

Did not read other posts, but I am planning on getting a mid performance PC and put Puppy Linux or $@#$@#$@#$@# Small Linux on it and Just make a program that does all the imaging and all that on the PC and communicating with the cRio with an ethernet cable plugged into port 2 (camera port) of the cRio and read here: http://www.ni.com/compactriodevguide/sec2.htm