Anyone interested in a Linux-based robot solution?

[Radical Pi]

Originally Posted by Gdeaver

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

I 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...roducts_id=211)
- Gumstix Chestnut43 I/O board (http://www.gumstix.com/store/catalog...roducts_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]

Originally Posted by 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...roducts_id=211)
- Gumstix Chestnut43 I/O board (http://www.gumstix.com/store/catalog...roducts_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/Dk...&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...oduct_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]

Originally Posted by taichichuan

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]

Originally Posted by 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.

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]

Originally Posted by dcherba

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.

Originally Posted by dcherba

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]

Originally Posted by dcherba

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.

Originally Posted by dcherba

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.

Originally Posted by dcherba

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.

Originally Posted by dcherba

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.

Originally Posted by dcherba

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.

Originally Posted by dcherba

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.

Originally Posted by dcherba

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