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.php/VEX_Arm9_Microcontroller
http://www.phidgets.com/products.php?category=21&product_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]

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]

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! :eek:
I was really hoping we could reduce the number of 'no robot code' problems next year -- not catapult them off the chart. ;-)

[taichichuan]

Mike, I have the deepest respect for you, but NOOOOOOO! :eek:
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]

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]

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]

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]

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

[Alex.Norton]

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 (http://firstforge.wpi.edu/sf/projects/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]

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]

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]

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]

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]

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.

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.

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 (http://firstforge.wpi.edu/sf/tracker/do/listTrackers/projects.wpilib/tracker) is open for business!

-Joe

[virtuald]

Has anyone considered contributing to this:

WPILib test harness (http://firstforge.wpi.edu/sf/projects/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]

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]

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.)

[Radical Pi]

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 think the ability to run code directly on the robot is a very important resource to have. I'm sure many of you who have been on the field (and the programmers too) have experienced the "control lag" that occurs when a robot begins sending an unusual amount of data over the network (major robot problems usually go with this). Now, instead of the controls taking that long to get there, imagine it's sensor values running back to a computer. Autonomous calculations would slow down immensely since all I/O is now running over a wi-fi network being shared with 5 other robots who could have major problems. The current FRC packet spec is a very light network footprint (apparently it's smaller than the minimum wi-fi packet), leaving only unusual situations in the laggy conditions.

Also, think about what HAS to be on the robot side. The system watchdog has to be on the robot (even more important because of the above paragraph), the NetworkCommunication library has to be running there, I/O interfaces have to be running. It just turns the 2CAN into a mini-cRIO that you aren't allowed to program. Much less power there.

And then think of all the problems you can run into with using a regular laptop to run the robot code. Under normal conditions, the only time a cRIO is on a shared network is when its on the field, where network security is locked down tight. But a laptop, on the other hand, is quite likely to be connected to the public Wi-Fi at an event (especially the programming laptop, which this would become). Now imagine a virus making its way onto a team's competition laptop. Now almost every single team at the competion has a virus. I remember from philly(?) that one of the inspection USB drives got a virus on it and spread to a few classmate computers. This virus prevented them from connecting to the field properly. It's a real problem

[Peter Johnson]

I've been exploring options for a Linux based robot controller for my own projects. Thoughts so far:

- Gumstix Overo Earth COM processor module (http://www.gumstix.com/store/catalog/product_info.php?products_id=211)
- Gumstix Chestnut43 I/O board (http://www.gumstix.com/store/catalog/product_info.php?products_id=237)

The Overo Earth has a 600 MHz OMAP3503 processor (ARM Cortex-A8 CPU), and 256 MB of RAM, so it's more powerful and has more memory than the cRIO. It will happily boot off a microSD expansion card (you can get 8-16 GB ones nowadays for cheap). Runs Linux like a champ.

The Chestnut43 board for the Overo provides Ethernet, USB console, and USB host interfaces. Ethernet is perfect to hook up to a wireless bridge, just like the cRIO. It also has a 40-pin expansion port which provides 6 PWMs, an I2C port, 6 A/D input lines, and 2 serial ports. Unfortunately, the expansion port is all 1.8V signals so a breadboard to level shift up to 5V signals is required to make this useful. I've not found something off the shelf to do this yet. It takes a 5V supply input, easy enough to grab off of the FIRST power distribution board, or alternatively you can get a 12V to 5V DC-DC converter pretty cheaply from DigiKey.

One thing I'm considering is designing and having fabricated a custom PCB design to replace the Chestnut43 board that would provide Ethernet, USB, 9-pin RS232, I2C, PWM-style 5V interfaces and be supplied from 12V, resulting in an entire robot controller in a size similar to that of the FIRST digital sidecar (and with similar interfaces, plus Ethernet and some analog inputs). If someone out there is interested in something like this, let me know! Of course, if it already exists, I would be even happier to not have to design it in the first place :).

If even more I/O is needed, the UBW32 (http://www.schmalzhaus.com/UBW32/) available from SparkFun has 3.3V and 5V I/O and can serve as a USB slave to the Overo. This is actually powerful enough to be a robot controller on its own, although it's more similar to the old IFI controller than the cRIO (e.g. it's a PIC microcontroller, not Linux capable, etc).

[taichichuan]

Hi Gang,

I've had good luck with this:

http://www.phidgets.com/products.php?product_id=1018

It's a USB-based device with 8 Digital in, 8 Digital out and 8 Analog in. It hooks up to shaft encoders and a whole raft of sensors. All of this via USB. I feel that the USB approach may have some merit because of the simplicity of the cables and the ability to buy them off the shelf if you don't already have a bucketload of them around the house. And, they've got libraries for all of it (open source) for Windows, Linux, and OS/X. We could probably port them to VxWorks and the WPILib approach easily enough. For most of the sensors, the USB cabling should be more than sufficient for the power draw.

As to using the laptop for most of the processing, I'd be concerned for the control lag that we saw on the field using the wireless. If anything, I'd be more interested in making the robot more, not less, autonomous. The 400 MHz PPC in the cRIO has way more than enough CPU and RAM for our purposes. The problem is the linear nature of the robot code that's running on the target CPU. Most teams weren't trying to use any multi-threading (does Labview even support this concept? It must, but I'm not sure) and were simply polling everything in the teleop control loop. This approach makes the CPU look to be 100% busy and provides poor performance all the way around.

Also, there were a *lot* of problems with the off the shelf video processing code. I seem to remember at least 3 copies of the image before we got an answer on what the camera was looking at. IMHO, that's just poor coding. But, it's also something that's easily fixed.

So, I don't think that it's the speed of the CPU that's the problem. It's the programming model that doesn't effectively use the resources that were supplied. There should be threads that look at the sensors and use decoupling mechanisms like message queues for communications. These things should be blocked most of the time and not burning any CPU time when they're not needed -- rather than being in the main teleop loop.

As for one of the earlier posts regarding the use of DKMs, I tend to agree. The flat address model in VxWorks if fraught with land mines if you're not careful. VxWorks does support a user-mode executable "real-time process". But, the WPILib would need to be built to be used in that kind of model before RTPs could become commonplace.

A shared library in Linux's protected memory model would certainly be "safer" IMHO because it would catch both NULL pointers and stack overflows -- the two most common errors in VxWorks development among the folks who use it for "real" applications.

Mike

[taichichuan]

I've been exploring options for a Linux based robot controller for my own projects. Thoughts so far:

- Gumstix Overo Earth COM processor module (http://www.gumstix.com/store/catalog/product_info.php?products_id=211)
- Gumstix Chestnut43 I/O board (http://www.gumstix.com/store/catalog/product_info.php?products_id=237)

The Overo Earth has a 600 MHz OMAP3503 processor (ARM Cortex-A8 CPU), and 256 MB of RAM, so it's more powerful and has more memory than the cRIO. It will happily boot off a microSD expansion card (you can get 8-16 GB ones nowadays for cheap). Runs Linux like a champ.



The Overo is a good little board and it's frequently used by the aerospace firms (Lock-Mart, NG, etc.) for control operations because it's cheap, fast, and with the PREEMPT_RT patch in place, capable of good determinism using Linux. It also runs quite nicely on a couple of AA batteries. With a set of USB I/O, the Overo board would be an excellent alternative. FWIW, you can also run VxWorks on it if you really wanted to.

Another option would be the Beagleboard:

http://search.digikey.com/scripts/DkSearch/dksus.dll?Cat=2621773&k=beagleboard

It's a little cheaper than the Overo and has USB I/O on it as well (same processor as the Overo). BTW, the OMAP 3530 on these boards includes a TI C6X DSP engine. Maybe not as hard core as the cRIO FPGA, but still better than relying on the CPU for everything.

The Phidgets SBC (http://www.phidgets.com/products.php?category=21&product_id=1070), is an ARM with 8 DI, 8 DO and 8 AIs built onto the board for about $260. And VEX has a new ARM 9 controller in the works with similar I/O capabilities. Once the WPILib is ported to Linux, then any of these inexpensive boards could be used with the same tool chain and O/S release. This would simplify the certification process if FIRST would consider it.

Mike

[Mark McLeod]

Most teams weren't trying to use any multi-threading (does Labview even support this concept? It must, but I'm not sure) and were simply polling everything in the teleop control loop. This approach makes the CPU look to be 100% busy and provides poor performance all the way around.

Just about everything in LabVIEW is multi-threaded, beginning with the opening of individual devices. It's automatic for the programmer. It's a pretty nice environment for training students in parallelism. One of the problems LabVIEW teams ran into this year was a lack of understanding that lots of things happened at essentially the same time, and you really don't want to be using a device before it's been opened.

Getting the robot system into more student hands without the limitation of accompanying expensive cRIO hardware is a great goal. The old IFI system presented the same problem. It too was beyond the mean$ of the typical student. The saving grace there was the abundance of spares that teams eventually accumulated.

I'd also like to see the common FRC community development of a simple, inexpensive robot-based system, such as some of these suggestions, that teams can use to keep past robots operating without the expense of a replacement cRIO. The biggest problem with that is the programming environment would almost certainly change in some respects for most teams, and a LOT of teams don't have the core CS mentorship support, or often any knowledge at all of programming or electronics.

As a drop-in replacement the 2CAN isn't capable as it now stands, since it's limited to jaguar CAN control only. No PWM victors/servos, digital I/O, etc. Because of the homemade cables required, it's not plug and play. It can't support existing robots to keep them running when the cRIO is pulled off for the next year.

[dcherba]

I am currently trying to get a roboard up and running under linux. It supports 32 pwms and 8 analog with multiple usb ports, serial ports, and a built in lan connections. It also supports some gpio on the 32 pwm ports. It should make a resonable practice bot platform.

Keep you all posted..

[EricVanWyk]

I think it is a fantastic idea to create your own control system(s). I learned a heck of a lot working on the 2009/2010FRC one. Please do not interpret any of the rest of this post as a suggestion that you shouldn't go for it: You Should Make Your Own Control System.

But, please examine your reasons for doing so carefully. If one of those reasons is "I want to fix something", please consider instead contributing to WPIlib! I believe that the system is nearing a point that it fundamentally can not improve beyond without direct, explicit user input. We all know what the bugs in the implementation are, and they are being worked on. What is hidden is the bugs in the underlying design of the user experience.

Several people have already submitted patches, and some of those have been accepted and put into the main line. Submit your own today! Go to the developers with specific and detailed information. They'd love to see things like: I was doing {use case description} and found myself doing {awkward work around description} because of { design flaw} , when really I should have been able to do { more intuitive user experience }.

You can not polish a design by starting over, no matter how many times you try. Quite the opposite happens.


Now, if your reason is either "The current system is fundamentally incapable of {X}" or "Dude, making our own system is going to be [fun / educational / totally wicked hawtsome ]", Rock On. I suggest talking to Squirrel or Keen101 - They have some really cool stuff in the pipeline already.

[taichichuan]

I think it is a fantastic idea to create your own control system(s). I learned a heck of a lot working on the 2009/2010FRC one. Please do not interpret any of the rest of this post as a suggestion that you shouldn't go for it: You Should Make Your Own Control System.

But, please examine your reasons for doing so carefully. If one of those reasons is "I want to fix something", please consider instead contributing to WPIlib! I believe that the system is nearing a point that it fundamentally can not improve beyond without direct, explicit user input. We all know what the bugs in the implementation are, and they are being worked on. What is hidden is the bugs in the underlying design of the user experience.

Several people have already submitted patches, and some of those have been accepted and put into the main line. Submit your own today! Go to the developers with specific and detailed information. They'd love to see things like: I was doing {use case description} and found myself doing {awkward work around description} because of { design flaw} , when really I should have been able to do { more intuitive user experience }.

You can not polish a design by starting over, no matter how many times you try. Quite the opposite happens.


Now, if your reason is either "The current system is fundamentally incapable of {X}" or "Dude, making our own system is going to be [fun / educational / totally wicked hawtsome ]", Rock On. I suggest talking to Squirrel or Keen101 - They have some really cool stuff in the pipeline already.

Well, there are a couple of primary motivations:

1) We need a way to be able to develop and test code in the absence of a cRIO.

This could be done via a cRIO simulator ala the Wind River Virtuatech (Simics) simulator. However, Simics is a 6-figure kind of product. And, then you've got to make the software models to make everything work. Not cheap, but it would have some value to National Instruments as well as the students.

2) We need a control system that is affordable by schools or individuals in larger numbers so students aren't limited to using just the cRIO during the build season but have something after the build season as well.

Related to #1. That is, enabling the students to work with a control system like the cRIO and WPILib at a more affordable price and without recurring subscription fees (as found in NI's robotics kit). Assuming that WRS isn't willing to pony up the cost of the Simics environment, we still need a way to help students learn basic control system techniques on a cost-effective platform. It can be argued that an O/S with Linux's protected mode memory model, is actually safer than the flat memory model in VxWorks (unless you try to teach the WRS Real-Time Process model). Either way, the WPILib would have to be enhanced to handle protected mode code. This benefits everyone.

3) There are elements of WPILib that are obscure at best and not consistent with current industry best practice.

This piece of it was not really related to the starting concept of the thread, because the original idea was to port the WPILib to make it platform agnostic; improving it for all platforms as we went. But, it appears that the thread touched a nerve. I have personal experience with the difficultly in using certain elements of the WPILib. Hopefully, everyone would come out ahead if we enhanced it to support a protected memory model and made fixes to usability as we went.

Whether or not FIRST approved the Linux solution for competition, just being able to have a faithful reproduction of the cRIO functionality for just a couple of hundred $ would be a big boost. It would be an emulation rather than a simulation. It could certainly support both the C/C++ and the Java environments. I don't have enough background with the Labview environment to know how well that development model would be supported. I can see that Labview supports Linux, but which CPU architectures isn't clear.

4) Finally, the process of getting a less expensive (and lighter!) version of the control system would, in fact, be fun.

I think many folks would benefit and the benefits to WPILib would also be tangible. Everybody wins.

Mike

[dcherba]

This thread has really touched on a number of issues without really taking a top down approach to identify them.

The Crio is a very capable box outfitted with the interfaces that were developed for the robot application.

The Crio is expensive when low budget teams look at the expense of multiple units. This will drive the teams to exploring alternative solutions for code development and practice robots.

Some of the standard software methods embedded in the hardware libraries are not as realtime friendly as they need to be. (image handling let a lone processing an image) I spent a lot of time digging in the libraries so that I would not shotgun solutions. The library skew on some of the releases and the multiple copies of things really caused a lot of confusion when trying to identify were the actual problems were. Having copies of the WPI libraries in three places was confusing.

The WPI library is an awsome start to robot control language interface.

The WindRiver tools with license issues can be a limiting factor.

The movement towards Java would reduce the dependency on the more expensive development tools and make the code development environment more available to more students.

There is no reason we can not develop a simulator for the basic WPI library that will run on either windows, or linux. The level of simulation and how to provide feedback is however complex.

I spent 20 years designing and applying programmable logic controller. The reason regular computers were not used in these control application is that the standard OS methods of thread control produce undesirable issues that degrade quality of control.

While the hardware is a great platform diving into the libraries to fix some of the quality of control issues will require a style of software methodology that we do not teach in computer science or engineering. In fact as faculty we would fail students if they used some of the methods required to solve the realtime control issues. (ironic actually)

There is a real differnce between designing something that works most of the time and something that works all the time for 30 years.

David Cherba

[Ether]

The reason regular computers were not used in these control application is that the standard OS methods of thread control produce undesirable issues that degrade quality of control.



diving into the libraries to fix some of the quality of control issues will require a style of software methodology that we do not teach in computer science or engineering. In fact as faculty we would fail students if they used some of the methods required to solve the realtime control issues. (ironic actually)


Hi David,

I am very interested in the above comments. Would you provide a bit more detail and perhaps an example or two of what you mean?

Thank you.


~

[taichichuan]

This thread has really touched on a number of issues without really taking a top down approach to identify them.

Well, that happens some times when you throw out ideas to generate discussion. You can't always know where the discussion will lead. But, I believe that I summarized the key points a couple of posts ago.


The Crio is a very capable box outfitted with the interfaces that were developed for the robot application.

The Crio is expensive when low budget teams look at the expense of multiple units. This will drive the teams to exploring alternative solutions for code development and practice robots.

I don't think that that issue has ever been in question. The cRIO is a very rugged piece of equipment. It's the cost of the unit and it's interfaces that are in question. So, we're simply exploring alternatives.

Some of the standard software methods embedded in the hardware libraries are not as realtime friendly as they need to be. (image handling let a lone processing an image) I spent a lot of time digging in the libraries so that I would not shotgun solutions. The library skew on some of the releases and the multiple copies of things really caused a lot of confusion when trying to identify were the actual problems were. Having copies of the WPI libraries in three places was confusing.

Yes, that was an issue as well. You're an experienced developer, so I would certainly hope that you wouldn't shotgun problems. But, many of the kids are not and they do. So, I feel that part of the issue to help them avoid that pitfall is to be able to provide a low-cost alternative so they can have more "ground time" to learn how to systematically debug failure modes.

The WPI library is an awsome start to robot control language interface.

I don't think that folks have questioned the validity of the WPI library as a good starting point. There are things that need to be fixed and we're starting a dialog to make that happen.

The WindRiver tools with license issues can be a limiting factor.

The movement towards Java would reduce the dependency on the more expensive development tools and make the code development environment more available to more students.

There is no reason we can not develop a simulator for the basic WPI library that will run on either windows, or linux. The level of simulation and how to provide feedback is however complex.

This is one of the reasons that I brought up Wind River's Simics. It's meant to be a simulation of a physical device with all of the I/O. However, the licensing is an issue. That's why it may be easier to emulate with real, low-cost hardware than simulate in a total software environment. I've found this to be true in many real-world applications.

I spent 20 years designing and applying programmable logic controller. The reason regular computers were not used in these control application is that the standard OS methods of thread control produce undesirable issues that degrade quality of control.

PLCs are great little devices for a number of control applications. However, whether you believe to be a good thing or not, there are a lot of operating systems in use in real-time and embedded control applications. And, those operating systems are in highly mission-critical applications. The PLCs are frequently adjuncts in such systems as the systems grow in complexity.

While the hardware is a great platform diving into the libraries to fix some of the quality of control issues will require a style of software methodology that we do not teach in computer science or engineering. In fact as faculty we would fail students if they used some of the methods required to solve the realtime control issues. (ironic actually)

I find this comment somewhat disturbing. This is precisely the subject of a paper I wrote for IEEE a couple of years ago:

http://www.todaysengineer.org/2008/Feb/help-wanted.asp

There has to be a place for taking the collective knowledge of our real-time and embedded engineers and passing them on to the next generation. The theory of software development needs to be tempered with the reality of meeting processing deadlines in safe and secure ways or we end up with the Toyota Prius problem. I'm working on pieces of the WPILib as we speak to try and make it more capable of running the robotics code without maxing out the CPU in polling loops. This will both teach good real-time engineering principles through example and make the cRIO more responsive. As a side effect, the WPILib can then be more easily ported to alternate platforms in the future.

In the FWIW category, the U.S. military has found that commercial of-the-shelf (COTS) boards are more than capable of operating in harsh and ruggedized environments. As someone who's gone through Navy tactical qualification with COTS hardware (they strap 2lbs of C4 to a barge w/ your equipment on it and detonate), I can attest to the resiliency of low-mass processor boards. So, I'd request that you don't reject a small board out of hand because it doesn't fit into the Allen-Bradley PLC form factor. You'd be surprised at how sturdy COTS equipment is.

Of course, equipment in FIRST isn't in the same "I set it up once and it has to last for 20 years" kind of environment. Our problems are much more fluid as the students experiment to find solutions to the problems posed by the GDC's *evil* imagination :p So, the cRIO is a good solution, but I don't think it's a cost-effective solution for cash-strapped school systems. I'm just trying to explore the alternatives.

Mike

[taichichuan]

A quick update from the Embedded Systems Conference in San Jose, CA... I had an opportunity today to talk with both Wind River and National Instruments folks about some of the ideas that we've been kicking around in this thread for either simulated or low-cost target boards for FIRST. They were quite receptive to our plight and we're going to continue the dialog to see how we can address the primary hardware access issues. They value our input and are with us in trying to help as many students as possible gain the experience they need to be successful in software development. This is very encouraging...

Mike

[Gdeaver]

If vision was separated out of the system, a light version becomes much easier.

[Greg McKaskle]

This thread has hit on a number of topics, and I'm playing catchup, so I'll comment on what I can.

Protected Memory Model:
The VxWorks OS version NI adopted for the cRIO only supports the unprotected, flat memory model. Because it would be such a nice feature, we investigated RTP support for FRC, with protected kernel and process layers, but this would involve upgrading to a newer version of VxWorks, redoing the OS image, redoing many of the drivers, etc. Additionally, the NI engineers who had already investigated this found the overhead of kernel transitions would have a big impact on the industrial I/O customer. Keep in mind that as sold to industry, the cRIO is a LV target. LV is a safe language, so running it on a safe OS benefits the NI engineers and the professionals who are writing their own .out extensions in C/C++, but isn't needed by the general user.

Since RTP turned out to be expensive to build, and unlikely to happen soon, I'd like to see the lib ported to a protected OS and run with an emulation layer. I'm currently looking at doing this for LV. This will be library level, not the entire OS, but I think it will be appropriate for finding logic bugs, compile problems, and teaching exercises as long as the feedback mechanisms are good.

As for the availability of cRIOs, and other control systems, NI and its suppliers are doing what they can for the pricing of the existing HW. Since the system will evolve, I'd love to hear the value of different features. I think everyone will agree that the industrial temperature spec has high cost and is of little value to FRC. Feedback on the other aspects of the HW that makes up the control system will be invaluable for FIRST to select or design the next control system.

Finally, there have been vague statements about how WPILib should be improved, but nothing specific enough to be actionable. Let me give my view of what WPILib is and is trying to be, then once again, ask for feedback.

My metaphor for WPILib is that of a big community swimming pool. It needs to have several pretty well defined zones that offer different levels of challenge and safety. It needs to support wading, general swimming activities, and for the daring, diving in head first trying to touch the bottom of the pool.

The framework and examples hopefully act as the wading zone. Lots of hand-holding, lots of prebuilt code that does simple things, allows for safe exploration as well as retreat. Since it exposes source, hopefully it serves to learn the next zone.

The general swimming is the actuator and sensor libraries themselves. You leave the framework entirely, or heavily modify it to add in and use many new elements in the library. Since it is distributed in source, it also supports exploration beneath the surface to see the dependencies, and the notification mechanisms that make up the higher level interfaces.

The deep diving, at least in LV is the NIFPGA interface. This exposes accumulators, triggers, and other raw forms of I/O which the general and wading layers are built from. It should allow for alternate implementations, alternate frameworks, and external sensors and actuators to be added in. At the moment this is as deep as the pool can go since the FPGA implements the safety mechanisms, and it doesn't seem appropriate for teams to modify the safety layer. Ideally, that layer will be opened up too, showing how to do encoders, PWM generation, triggers, integrators, etc on an FPGA.

Obviously, the current implementation is only one potential way of doing things, and honestly, the pool was opened while still under construction, and probably always will have some areas under construction. Again, feedback is super important. All of the zones were built at the same time, not enough documentation exists, and there are many alternate implementations that should be considered.

I've created three feedback threads on the technical/control systems/FRC control systems and on the technical/programming pages. Hopefully that will allow for the feedback to take place without intruding on this thread.

Greg McKaskle

[dcherba]

A type example is the way protocol stacks are built and copied. In the realtime critical environment we utilize large but fixed size circular buffers that have overrun protection and full 4 level handshake on interface that does not require coping blocks of data from thread to thread. The interupt handlers are designed to minimize context switch and often only require a few bytes to be saved and restored reducing the overhead of the time slice needed to work on a packet. This style avoids the mutex issue and what often leads to thread lock problems.

It is amazing when I count the number of thread lock events that occur every 24hours even in robust systems.

While I agree with the robust abilities of many small hardware platforms the idea of mounting the crio on insulated materials to protect it goes against every real world experience I have with building industrial tough computers.

I am just returning to the FIRST community after finishing graduate school and completely changing from the controls field to bioinformatics. I have not started looking too deeply at the crio and the wpilib but trying to use the video camera and seeing the protocol induces watchdog timer errors was disturbing.

I applaud all of you that have helped make the wpilib a reality and like my earlier post think it is great. Some of the crio hardware libraries I looked at really need to be redone in order to be reliable. The camera software relies on some low level routines that are absolute time slice hogs and until they are fixed no amount of low resolution will stop the 50-100millisec slices.

As I get more up to speed I will start posting suggestion and fixes. I wrote my own timer class this year which functions more like timers in the PLC's and it allowed our control program in autonomous to be extremely small and robust. Hope to get that posted soon. It was interesting to build that because many of the gettime functions that are standard on every os did not operate as expected or documented. What should have been a two hour project turned into 3 days of real head scratching and looking at more header files than I knew existed for stdio. That is an example of what really eats your time even when you are very experience let alone a student attempting these types of things for the first time.


Dave

[biojae]

The deep diving, at least in LV is the NIFPGA interface. This exposes accumulators, triggers, and other raw forms of I/O which the general and wading layers are built from. It should allow for alternate implementations, alternate frameworks, and external sensors and actuators to be added in. At the moment this is as deep as the pool can go since the FPGA implements the safety mechanisms, and it doesn't seem appropriate for teams to modify the safety layer. Ideally, that layer will be opened up too, showing how to do encoders, PWM generation, triggers, integrators, etc on an FPGA.



Is there a way that any of the implementation can be exposed?
Maybe only the things you mentioned (encoders, PWM, triggers, etc.) without comprimising any of the safety layer.
Even a screen shot would be better then the virtual "black box" that it is now.
Some knowledge of how the system works would help diagnose some issues, even if they can't be directly fixed (indirectly through bug reports).

[Greg McKaskle]

If you are pretty convinced there is a bug in something, I suppose we could give out a screenshot to help get to the bottom of it, but again, since this is the safety protocol, we wouldn't want any enterprising team to "optimize" it, resulting in someone getting hurt. So whatever we'd do we'd keep FIRST in the loop.

Trust me, NI and especially Xilinx would like you to have access.
Greg McKaskle

[biojae]

If you are pretty convinced there is a bug in something, I suppose we could give out a screenshot to help get to the bottom of it, but again, since this is the safety protocol, we wouldn't want any enterprising team to "optimize" it, resulting in someone getting hurt. So whatever we'd do we'd keep FIRST in the loop.

Trust me, NI and especially Xilinx would like you to have access.
Greg McKaskle

I haven't noticed any bugs, at least in what I have experimented with,
but as a non-FIRST project I would like to start working with a FPGA.

I understand the concern for safety, though it shouldn't be in every VI especially in the ones used for input (Accumulator, encoder, etc.).

Could the ones that wouldn't comprimise the safety layer be released somehow, or somewhere(Firstforge)?

[Radical Pi]

Not intending to derail the topic, but I guess it is somewhat related.

This is mainly to Greg: Is the possibility of including the FPGA module of LabVIEW in the FRC edition being considered? Even if FPGA code mods aren't allowed by FRC rules (similar to how the grey jags were made with CAN capabilities that weren't allowed in 09), it still would be put to use by teams doing off-season stuff with the cRIO that require FPGA changes (using different modules comes to mind). Even if it isn't FRC legal, the learning and experimenting with it (something I love to do) is great for the programmers (and great marketing too :P). And on the safety problem, what about just giving us the regular code with the safety things stripped out of it?

[Greg McKaskle]

Personally I think the FPGA tools would be a great addition for offseason projects.

Perhaps you want to measure gas exchange in your local rain forest, or connect it to your neighborhood hadron collider, make an engine controller for your motorcycle, or send it up in a rocket to perform flight control, ... just as long as it doesn't involve driving somewhat powerful robots without the appropriate safety mechanisms.

At the moment I'd say your best bet is to write a letter or build a presentation explaining why you'd like the tools and asking for a license. Treat it like a fund raising event. If you need additional ideas, poke around on http://www.ni.com/solutions/. Send the request to either your local sales representative or to someone at NI corporate in the academic department. If you can't find someone, send it to me.

Greg McKaskle

[taichichuan]

Can anyone provide some idea of what types of safety protocols are provided in the FPGA? I don't need the specifics of the code, but if we're trying to simulate the system in software, we need to have an understanding for what safety we're trying to implement. Is it like a current limiting governor, or a sample rate limitation or what? And, did we implement any of these safety interlocks before the cRIO came into the picture? if so, how did we do it before the slick FPGA?

TIA,

Mike

[AustinSchuh]

I'm going to give my best educated guess, which will be pretty close.

Before the cRIO, the IFI system had 2 CPU's in it. One CPU dealt with communications and the safety protocols. Eg: if it didn't see a packet from the driver station within a set amount of time, it would put the robot in disabled mode and disable all the motors. We weren't allowed to change the code on that CPU, and could only change code on the other CPU in the system.

On the cRIO, I'm pretty certain that the FPGA kills the motors if it doesn't see a packet from the Driver Station within enough time, or gets a disabled signal, or gets an e-stop signal. So, it's serving the same purpose as the IFI system's second CPU. It probably also implements the watchdog. This makes it so that if we totally mess up the software as users, if someone tries to kill the robot, the robot will stop.

To sum it up, you want to have some sort of safety system that won't rely on end user code (that can have bugs in it) to stop the robot when it looses comms, gets a disabled signal, or an e-stop signal.

[taichichuan]

I'm going to give my best educated guess, which will be pretty close.

Before the cRIO, the IFI system had 2 CPU's in it. One CPU dealt with communications and the safety protocols. Eg: if it didn't see a packet from the driver station within a set amount of time, it would put the robot in disabled mode and disable all the motors. We weren't allowed to change the code on that CPU, and could only change code on the other CPU in the system.

On the cRIO, I'm pretty certain that the FPGA kills the motors if it doesn't see a packet from the Driver Station within enough time, or gets a disabled signal, or gets an e-stop signal. So, it's serving the same purpose as the IFI system's second CPU. It probably also implements the watchdog. This makes it so that if we totally mess up the software as users, if someone tries to kill the robot, the robot will stop.

To sum it up, you want to have some sort of safety system that won't rely on end user code (that can have bugs in it) to stop the robot when it looses comms, gets a disabled signal, or an e-stop signal.

OK, that can be dealt with easily enough through a uP like the ATMEL ATMega. Also, Xilinx has recently announced some hard-core ARM and PPC440 processors w/ 10000+ FPGA gates on them that could be used for the safety and still run Linux. I was just trying to make sure there wasn't something more sophisticated.

Thanks,

Mike

[jhersh]

To sum it up, you want to have some sort of safety system that won't rely on end user code (that can have bugs in it) to stop the robot when it looses comms, gets a disabled signal, or an e-stop signal.

You got it.

OK, that can be dealt with easily enough through a uP like the ATMEL ATMega. Also, Xilinx has recently announced some hard-core ARM and PPC440 processors w/ 10000+ FPGA gates on them that could be used for the safety and still run Linux. I was just trying to make sure there wasn't something more sophisticated.

It can certainly be done on a different hardware platform... in fact the new Xilinx parts sound like a pretty similar architecture.

[Greg McKaskle]

Rather than go into the details, not sure that I'd do it very accurately anyway, find a way for the "dangerous" outputs to have a trusted element that can shut them down when things aren't updated or when the field explicitly requests it.

On the cRIO, there are several trusted pieces that pose challenges to each other to make pretty sure they are legit. The FPGA ultimately controls the PWMs, relays, and solenoids, CAN doesn't go through the FPGA, but includes info from the FPGA to generate the keys for the jag heartbeats. If/when this project goes further, ask for more details.

Greg McKaskle