2009 Control System Feature Wishlist

[Daniel_LaFleur]

I guess my wishlist would start with being able to framegrab and run image recognicion (sp?) using multiple, inexpensive USB webcams (ethernet cameras are so expensive).

[acdcfan259]

For the controller to control the robot...flawlessly.

[jhersh]

Originally Posted by Daniel_LaFleur

I guess my wishlist would start with being able to framegrab and run image recognicion (sp?) using multiple, inexpensive USB webcams (ethernet cameras are so expensive).

Since the controller does not have USB ports, that will be problematic. You would need to have an external interface board that supports both ethernet and USB, then write software for it to shuffle the data between the busses. It would probably end up being more expensive, take up more space, be more complex and have lower performance than simply using an ethernet camera.

How expensive is "so expensive"? How does that cost compare with USB cameras? How about compared to the cost of the CMUcam? Are you considering any specs of the cameras besides the interface?

-Joe

[Daniel_LaFleur]

Originally Posted by jhersh

Since the controller does not have USB ports, that will be problematic. You would need to have an external interface board that supports both ethernet and USB, then write software for it to shuffle the data between the busses. It would probably end up being more expensive, take up more space, be more complex and have lower performance than simply using an ethernet camera.

How expensive is "so expensive"? How does that cost compare with USB cameras? How about compared to the cost of the CMUcam? Are you considering any specs of the cameras besides the interface?

-Joe

I can get a 30fps @ 640x480 for $19.99 here (yeah, I know ... it looks like mr burns ). As long as the resolution/focal length is acceptable then all that would be needed is a USB interface into the cRio (**wishes**)

The CMUcam is $239.00 here and still needs an interface as it's serial (I haven't seen any serial interface on the cRio).


And the thing I was really interested in, though, was the ability to Frame Grab and IR with multiple cameras.

[jhersh]

Originally Posted by Daniel_LaFleur

I can get a 30fps @ 640x480 for $19.99 here (yeah, I know ... it looks like mr burns ). As long as the resolution/focal length is acceptable then all that would be needed is a USB interface into the cRio (**wishes**)

The CMUcam is $239.00 here and still needs an interface as it's serial (I haven't seen any serial interface on the cRio).


And the thing I was really interested in, though, was the ability to Frame Grab and IR with multiple cameras.

The primary reason that the cRIO doesn't have USB is that, for industrial automation and control (the primary market), USB is rarely used. If a USB interface is needed, then a solution like I described above must be employed.

Ethernet cameras can be found for around a hundred dollars for low quality to a few hundred for decent quality imaging.

The cRIO has an RS232 serial port on it.

Cheers!
-Joe

[whytheheckme]

Originally Posted by jhersh

Ethernet cameras can be found for around a hundred dollars for low quality to a few hundred for decent quality imaging.

I bought some Ethernet cameras off of Woot! for $20 last year (640x480 if I'm not mistaken.)

-Jacob

[DtD]

Because our school's wireless is PEAP-based, I would love if it could connect to that considering that the place most of the programming is done is far out of range of the workshop.

Also, it would save alot of trouble if the OI could easily be powered by battery for testing.

~DtD

[Daniel_LaFleur]

Originally Posted by jhersh

The primary reason that the cRIO doesn't have USB is that, for industrial automation and control (the primary market), USB is rarely used. If a USB interface is needed, then a solution like I described above must be employed.
<<SNIP>>
-Joe

This actually surprises me, considering the number of USB DAQ devices ( like this, and this) entering the market. Attaching a simple driver circuit (either voltage or current) to one of the USB DAQ DOs allows for control of most pneumatic systems and some DC motors (single directional / single speed) while the limited AOs can control many of the more sophisticated motor systems.

Not to mention the sheer number of other USB devices that the cRio could control (Enviromental control and monitoring, control feedback through DAQs, Logic instrumentation, ocilliscope signals, etc) and all through a common port (latency, timing, and bandwidth would be an issue on the higher end devices).

This would seem to me to be an easy way to expand the cRio's capabilities while keeping the cost to the end user down.

JMHO

[jhersh]

Originally Posted by Daniel_LaFleur

This actually surprises me, considering the number of USB DAQ devices ( like this, and this) entering the market. Attaching a simple driver circuit (either voltage or current) to one of the USB DAQ DOs allows for control of most pneumatic systems and some DC motors (single directional / single speed) while the limited AOs can control many of the more sophisticated motor systems.

Not to mention the sheer number of other USB devices that the cRio could control (Enviromental control and monitoring, control feedback through DAQs, Logic instrumentation, ocilliscope signals, etc) and all through a common port (latency, timing, and bandwidth would be an issue on the higher end devices).

This would seem to me to be an easy way to expand the cRio's capabilities while keeping the cost to the end user down.

JMHO

It is true that there are many USB data acquisition systems out there, but there is a reason they are not used for control. The bus latency and non-determinism are detrimental to control systems above around 250Hz. The USB only tries to send data to or from the device every 1ms (125us for high speed) or less, depending on bus utilization. Fundamentally, that is why they are called data acquisitions systems and the cRIO is called a programmable automation controller.

You'll notice that even for the cSeries IO modules, we have different chassis to use them in, such as the NI cDAQ-9172 chassis. This chassis is USB and can interact with the same modules that come in the kit. This is for reading lots of data very fast or writing lots of data very fast. It is not made for the read-compute-write single point data path that is needed for control systems.

I hope this clarifies the reason why USB is not used for control. If you have more questions, I'd be glad to attempt to answer them.

Cheers!
-Joe

[Daniel_LaFleur]

Originally Posted by jhersh

It is true that there are many USB data acquisition systems out there, but there is a reason they are not used for control. The bus latency and non-determinism are detrimental to control systems above around 250Hz. The USB only tries to send data to or from the device every 1ms (125us for high speed) or less, depending on bus utilization. Fundamentally, that is why they are called data acquisitions systems and the cRIO is called a programmable automation controller.

You'll notice that even for the cSeries IO modules, we have different chassis to use them in, such as the NI cDAQ-9172 chassis. This chassis is USB and can interact with the same modules that come in the kit. This is for reading lots of data very fast or writing lots of data very fast. It is not made for the read-compute-write single point data path that is needed for control systems.

I hope this clarifies the reason why USB is not used for control. If you have more questions, I'd be glad to attempt to answer them.

Cheers!
-Joe

First off, Joe, I want to thank you for this discussion thread. The information here will be invaluble to students that do not understand bus architecture / limitations (something I know a bit about )

Now on the the method behind my madness :

Our old controller gave us a 40ms slow loop (where we could write PWM outputs). Given that, the capabilities of USB 2.0 (even with latency) would be a dream. I wasn't suggesting USB for output control (even though, in some cases it's possible) but instead for data input from cameras and other sensors.

Now my guess is that the cRio (I havent seen a datasheet on the base unit yet) uses either CAN, PXI or a PCI express bus (My guess is CAN bus). The FIRST demonstration (not really complete ) showed a single ethernet camera at 640x320, 15fps, full color. This (to me) didn't seem to tax either the ethernet port nor the bus/processor but is stated as the capabilities of the cRio. This is why I was looking for USB connectivity and webcams.

So I guess my question is ... is the (FIRST configuration) cRio capable (framgrab and IR) of more than than 1 camera at this framerate? higher framerates at lower resolution? higher framerates at lower color? Multiple cameras (at all)?

[jhersh]

Originally Posted by Daniel_LaFleur

First off, Joe, I want to thank you for this discussion thread. The information here will be invaluble to students that do not understand bus architecture / limitations (something I know a bit about )

I hope that in the course of transitioning from the old platform to this new one, we can share the design decisions that led up to the ultimate design for the system that the students and mentors will work with. I think an understanding of how we made the choices we made will help them to make better use of the system.

Originally Posted by Daniel_LaFleur

Our old controller gave us a 40ms slow loop (where we could write PWM outputs). Given that, the capabilities of USB 2.0 (even with latency) would be a dream. I wasn't suggesting USB for output control (even though, in some cases it's possible) but instead for data input from cameras and other sensors.

I realize that you weren't asking for that particular I/O expansion. I was responding to the assertion that you made concerning the use of USB DAQ products in general with the cRIO. It is true that some slow control applications can use USB, but the typical application of that doesn't use cRIO as the primary controller. Instead, a single board computer or even a PDA will be used. As such, the typical high-speed, high-reliability applications that demand cRIO, can not abide a USB interface to the real world. That is the reason that the commercial cRIO has no USB port. We did put USB on an old model (cRIO-9012) which supported mass storage devices like memory sticks at full speed (USB 1.1). There was no real demand to either make it USB 2.0 or to support other types of devices, so it was left out of later designs.

Because the cRIO for FIRST teams will fundamentally be a stock commercial cRIO, the addition of USB to the controller is not possible.

Originally Posted by Daniel_LaFleur

Now my guess is that the cRio (I havent seen a datasheet on the base unit yet) uses either CAN, PXI or a PCI express bus (My guess is CAN bus). The FIRST demonstration (not really complete ) showed a single ethernet camera at 640x320, 15fps, full color. This (to me) didn't seem to tax either the ethernet port nor the bus/processor but is stated as the capabilities of the cRio. This is why I was looking for USB connectivity and webcams.

So I guess my question is ... is the (FIRST configuration) cRio capable (framgrab and IR) of more than than 1 camera at this framerate? higher framerates at lower resolution? higher framerates at lower color? Multiple cameras (at all)?

The cRIO does support CAN by using an NI 9853, but it is not supported natively on the controller. The primary interface to the cRIO is Ethernet.

In the demo, the cRIO was not heavily taxed to simply stream the image back to the PC, and the Ethernet port certainly wasn't saturated. I imagine multiple ethernet cameras would be straight forward to get going if a switch were used to attach both of them. The real problem comes when you try to do video processing on the images. At that point, I think the processor in the cRIO will be very heavily taxed and the frame rate of processing will likely be significantly less than the rate that the images come from the camera. Naturally this depends a lot on what you are trying to do and how efficiently you implement it.

Cheers!
-Joe

[Greg McKaskle]

If the goal of multiple cameras is to have a view in multiple directions, a single camera can do this with a mirror and some math. Point the camera straight up. Mount a curved mirror -- a hyperbolic is best, but simple mirrored Christmas balls can work. The image from the camera contains information from all around the camera, but it is distorted due to the shape of the ball. A math transform lets you put the pixels onto a cylinder, letting a single camera see everything around it.

Not the same as stereo-optic vision, but much simpler, and perhaps useful on a crowded field of robots.

Greg McKaskle

[Daniel_LaFleur]

Originally Posted by Greg McKaskle

If the goal of multiple cameras is to have a view in multiple directions, a single camera can do this with a mirror and some math. Point the camera straight up. Mount a curved mirror -- a hyperbolic is best, but simple mirrored Christmas balls can work. The image from the camera contains information from all around the camera, but it is distorted due to the shape of the ball. A math transform lets you put the pixels onto a cylinder, letting a single camera see everything around it.

Not the same as stereo-optic vision, but much simpler, and perhaps useful on a crowded field of robots.

Greg McKaskle

My reasoning for asking this is that i believe that FIRST will 'up the ante' when it comes to game complexity because of the advanced features available in the cRIO.

Up until now the vision system used in FIRST has only had to track a single, non-moving, known sized (usually illuminated) target. Thus, it's my belief that FIRST will challange the teams with either (or a combination of) multiple targets, moving targets or targets where their form, color or shape may change.

With 2 cameras and a known distance between them I can calculate distance to a target ... and with 2 frames from each I can calculate the vector (curve with 3 frames, if needed) in 3D and thus estimate a target location at a future time.

Your suggestion of a parabolic mirror (sounds like a fish-eye lens effect) looks like it could answer the multiple targets possibilities but may make image recognition a bit difficult (depending on mirror quality, orientation of the target, distance, etc).

From the answers above, it sounds like the cRIO is quite capable of reading from multiple cameras, but that the processing power may limit the framerate. This leads me to another question. Will the LabView program supplied to FIRST teams be able to compile to processors other that the cRIO PowerPC (Like an ARM processor running linux in a Gumstix)?

P.S. In case it sounds like I'm whining for more ... I want you all to know I love the cRIO. It's a wonderful system, and I can't wait to get my software teams hands on it.

[Greg McKaskle]

Originally Posted by Daniel_LaFleur

Your suggestion of a parabolic mirror (sounds like a fish-eye lens effect) looks like it could answer the multiple targets possibilities but may make image recognition a bit difficult (depending on mirror quality, orientation of the target, distance, etc).

... Will the LabView program supplied to FIRST teams be able to compile to processors other that the cRIO PowerPC (Like an ARM processor running linux in a Gumstix)?

P.S. In case it sounds like I'm whining for more ... I want you all to know I love the cRIO. It's a wonderful system, and I can't wait to get my software teams hands on it.

If you've seen the virtual walkthrough's realtors often put on websites, then you've seen the results that a good camera with a good exposure can produce. They are often produced with this sort of setup on a tripod. Then processed into an interactive cylinder.

LV realtime currently supports two processor architectures, x86 and PPC. LV supports other desktop varieties, though not officially anymore. And then there are the embedded tools which actually compile to C, which is then sent through other tools to target processors such as the ARM. So technically LV can target the ARM, but the dev cycle isn't quite the same as RT.

Whining on a wish list, ... I think that is what it is hear for.

Greg McKaskle

[Mike Mahar]

My biggest wish is to get the controller and the default code as soon a possible. I know that I'd be willing to accept the fact that there will be bugs in both the FPGA and the libraries. Heck, there will be bugs in those systems regardless of when we get them so it would be better for all if the FIRST community could find them early and have a better chance of getting them fixed in time for the competition.