Is the crio powerful enough?

[Ether]

On a 3.4GHz Pentium D, the sin() function is about 3 times slower than a 3rd degree polynomial approximation.

But since we're only talking 0.3 microseconds for the sin() function, it's not to worry. Anybody have numbers for the cRIO, just curious?

[biojae]

Which vision target are you designing for?
Green light (2005 - 2007) / Pink and green (2009)
Concentric ellipses

If it is the first one then the cRio might be able to process it.
The thresholding operations take much less processing power.

Are you trying to use stereoscopic vision techniques, or just triangulation?

[davidthefat]

Originally Posted by biojae

Which vision target are you designing for?
Green light (2005 - 2007) / Pink and green (2009)
Concentric ellipses

If it is the first one then the cRio might be able to process it.
The thresholding operations take much less processing power.

Are you trying to use stereoscopic vision techniques, or just triangulation?

The target is any target really, its not specific targets, but just an object that has similar colors. I will go further and do object identification, but I am not thinking that far ahead, Its just alot easier to use an IR Rangefinder and probably more accurate, but I want it to be actually useful. Also 3d mapping is one idea I have in my head

[EricVanWyk]

Originally Posted by Ether

On a 3.4GHz Pentium D, the sin() function is about 3 times slower than a 3rd degree polynomial approximation.

But since we're only talking 0.3 microseconds for the sin() function, it's not to worry. Anybody have numbers for the cRIO, just curious?

Ether -

How did you measure 0.3 microseconds?

I recently wrote a sin function that runs in ~0.7 microseconds on an 80MHz Arm Cortex-M3, with comparable accuracy.

[PAR_WIG1350]

Originally Posted by EricVanWyk

Ether -
How did you measure 0.3 microseconds?

you don't, you just perform the same operation a few million times and divide.

[kamocat]

Originally Posted by PAR_WIG1350

you don't, you just perform the same operation a few million times and divide.

I don't suppose there's any reason to perform it with changing input values, is there? Computers take just as long to multiply 0x0 as they do 57x291, correct?

Just in case, I used a random-number generator. (This prevents LabVIEW from compiling the results as constants in the program)


It took about 0.000492ms per iteration of the sine function, measured over a million iterations. To put it on the same scale as Ether's measurement, that's 0.5 microseconds.

[biojae]

Like what was said previously, the trig is not going to be a problem instead its the vision proc.

The triangulation tracking won't take much more processing then 2 *(current load for 1 camera + pointing).

However, a 3d disparity map for stereo optics will take the load of the previous as well as the load of the calculations to make the map and then find a target and distance.

Here is a whitepaper on stereo optics
http://www.cse.unr.edu/~bebis/CS791E...ereoCamera.pdf

[EricVanWyk]

Originally Posted by kamocat

I don't suppose there's any reason to perform it with changing input values, is there? Computers take just as long to multiply 0x0 as they do 57x291, correct?

Actually, that isn't always true. For example, the Cortex-M3 multiply timing follows:
32 bits x 32 bits = 32 bits is always one cycle
32b x 32b = 64b takes 3 cycles if the result is small
32b x 32b = 64b takes 5 cycles if the result is big

Also, it is relatively common for functions to bail early for special values, such as 0. For example, my sine function bails in less than half of the usual execution time if the input is a multiple of 45 degrees.

Originally Posted by kamocat

Just in case, I used a random-number generator. (This prevents LabVIEW from compiling the results as constants in the program)


It took about 0.000492ms per iteration of the sine function, measured over a million iterations. To put it on the same scale as Ether's measurement, that's 0.5 microseconds.

Thanks!

[davidthefat]

I was not very aware of FPGAs, so I read up on them; essentially FPGAs are processors that are highly customizable to fit specific functions? So do FPGAs need to be configured hardwarely before it can be programmed? Is the cRio a type of FPGA? If not, which FPGA is a suitable FPGA for the purpose of image processing? Also would the FPGAs be used primarily to capture the images or process the images? Regarding cameras, would they need to be directly communicating with the FPGA, like the middle man, or would the cameras be communicating with the cRio? If the cameras were to be communicating with the cRio, would a Ethernet network cable splitter suffice? Would the cameras show up as two separate cameras or would the set up just fail?

[kamocat]

An FPGA is not a processor. It does not have to work with only four bytes at a time. It doesn't have to grab data from a register, manipulate it, and then put it somewhere else in memory; it can just process the data continuously. It runs in parallel, like analog hardware. Think of it as a million operational amplifiers you can connect in whatever pattern you like, but instead of having to remanufacture it each time, you can reconfigure it electronically. In truth, it actually loads its configuration from non-volatile memory each time it is turned on, as opposed to it being burned in like a CD.

On the cRIO, there is a processor and an FPGA. I'm not sure about the ethernet or RS232, but I know that every one of the eight modules goes through the FPGA to get to the processor. For example, a small part of our FPGA is programmed as an accumulator for the gyro, to integrate degrees/second into absolute degrees. The FPGA is also used to improve the performance of the processor by acquiring data so that interrupts are rarely necessary; when the processor requests an input, the data is right there.

Now, as to how to get access to the FPGA: We aren't given the LabVIEW FPGA module in FRC. That's because

1. It's believed to be too difficult for highschoolers in 6 weeks.
2. It contains the system watchdog, and FIRST would be worried about safety hazards if it is disabled.
3. It is a very valuble product of National Instruments, and it's a lot of what prevents loss of profit through piracy of the software we get for free. If we were to buy this software and a cRIO, it would be around $8,000 (single license).

Now, with that said, if you download a trial of LabVIEW, you have 30 days to play with it. LabVIEW 2010 just came out yesterday. It is common to have multiple versions of LabVIEW on a single computer without conflict, but if you like, feel free to back it up. After the 30 days, you license will expire, but your code will still be functional if it is deployed. If you'd like to use your code in LabVIEW 8.6, make sure to back-save it so that you can open it with the earlier version of LabVIEW.
When you'd like to use the cRIO for FIRST again, you will have to re-image.

[davidthefat]

Originally Posted by kamocat

An FPGA is not a processor. It does not have to work with only four bytes at a time. It doesn't have to grab data from a register, manipulate it, and then put it somewhere else in memory; it can just process the data continuously. It runs in parallel, like analog hardware. Think of it as a million operational amplifiers you can connect in whatever pattern you like, but instead of having to remanufacture it each time, you can reconfigure it electronically. In truth, it actually loads its configuration from non-volatile memory each time it is turned on, as opposed to it being burned in like a CD.

On the cRIO, there is a processor and an FPGA. I'm not sure about the ethernet or RS232, but I know that every one of the eight modules goes through the FPGA to get to the processor. For example, a small part of our FPGA is programmed as an accumulator for the gyro, to integrate degrees/second into absolute degrees. The FPGA is also used to improve the performance of the processor by acquiring data so that interrupts are rarely necessary; when the processor requests an input, the data is right there.

Now, as to how to get access to the FPGA: We aren't given the LabVIEW FPGA module in FRC. That's because

1. It's believed to be too difficult for highschoolers in 6 weeks.
2. It contains the system watchdog, and FIRST would be worried about safety hazards if it is disabled.
3. It is a very valuble product of National Instruments, and it's a lot of what prevents loss of profit through piracy of the software we get for free. If we were to buy this software and a cRIO, it would be around $8,000 (single license).

Now, with that said, if you download a trial of LabVIEW, you have 30 days to play with it. LabVIEW 2010 just came out yesterday. It is common to have multiple versions of LabVIEW on a single computer without conflict, but if you like, feel free to back it up. After the 30 days, you license will expire, but your code will still be functional if it is deployed. If you'd like to use your code in LabVIEW 8.6, make sure to back-save it so that you can open it with the earlier version of LabVIEW.
When you'd like to use the cRIO for FIRST again, you will have to re-image.

Now that just confused me even more . So I do not have access to the cRio FGPA? I won't be using LabView, and never plan to; I use C++. I guess the possibility of using an on board computer to process the images is certainly a possibility. I doubt beagle board is strong enough; a standard PC would violate the rules (BIOS Battery). Even without those, the project is a big hole in the wallet; the cameras them selves are around $80.

[gblake]

Originally Posted by kamocat

An FPGA is not a processor...

I agreed with everything in the quoted post except for the first sentence (above).

Many of the ways an FPGA can be used are the definition of "processing" digitized data; and the inevitable consequence of that, is that an FPGA is (among other things) a type of "processor".

FPGA's certainly are not one of the typical CISC/RISC Central Processing Units usually found at the heart of a desktop computer or of many embedded computing products; but "processor" is certainly one of the ways they can be configured and used.

Blake

[jhersh]

Originally Posted by kamocat

Now, as to how to get access to the FPGA: We aren't given the LabVIEW FPGA module in FRC. That's because

1. It's believed to be too difficult for highschoolers in 6 weeks.
2. It contains the system watchdog, and FIRST would be worried about safety hazards if it is disabled.
3. It is a very valuble product of National Instruments, and it's a lot of what prevents loss of profit through piracy of the software we get for free. If we were to buy this software and a cRIO, it would be around $8,000 (single license).

The first 2 points are accurate. The 3rd point about piracy is not a contributing factor for it not being included in the kit. We trust that teams will be responsible with the software they are given.

[biojae]

Originally Posted by davidthefat

I was not very aware of FPGAs, so I read up on them; essentially FPGAs are processors that are highly customizable to fit specific functions? So do FPGAs need to be configured hardwarely before it can be programmed? Is the cRio a type of FPGA? If not, which FPGA is a suitable FPGA for the purpose of image processing? Also would the FPGAs be used primarily to capture the images or process the images? Regarding cameras, would they need to be directly communicating with the FPGA, like the middle man, or would the cameras be communicating with the cRio?

The cRIO has an FPGA in it. This is what produces the PWM signal on the digital sidecar, accumulates the gyro signal, and communicates with all of the modules in the RIO.
It also provides the system watchdog.

Most FPGAs are programmed over JTAG, they only need power (some need 3.3v for IO as well as 1.75v for the main processor) and a clock to be programmed.
Keep in mind that some of them are volatile, they lose their program upon power down, so those ones need an external flash memory in order to function properly each time it is powered up.

As far as capturing / processing goes, the FPGA could do both (if you use one that has enough NAND (or NOR) gates).

If to be used for capturing, then it would have to be a "middle man" between the camera and the cRIO.
This would allow all of the processing to be done without putting ANY load on the cRIO. It would appear be something like a CMUCam to the cRIO.

The CMUCam would give the RC a very limited set of data (but the data was useful). It gave the centroid's (Center of mass) coordinates, 2 coordinates (a box where the green target was found), and servo control commands to keep the target centered.

Originally Posted by davidthefat

If the cameras were to be communicating with the cRio, would a Ethernet network cable splitter suffice? Would the cameras show up as two separate cameras or would the set up just fail?

You would need a hub or switch, not just a splitter.
Each camera would have its own IP address (unless your processing FPGA is what is ultimately communicating to the cRIO, in which case no cameras would show up, the only data transferred would be in your own custom protocol and with your own data.) and thus would show up as 2 cameras.

[davidthefat]

Originally Posted by biojae

The cRIO has an FPGA in it. This is what produces the PWM signal on the digital sidecar, accumulates the gyro signal, and communicates with all of the modules in the RIO.
It also provides the system watchdog.

Most FPGAs are programmed over JTAG, they only need power (some need 3.3v for IO as well as 1.75v for the main processor) and a clock to be programmed.
Keep in mind that some of them are volatile, they lose their program upon power down, so those ones need an external flash memory in order to function properly each time it is powered up.

As far as capturing / processing goes, the FPGA could do both (if you use one that has enough NAND (or NOR) gates).

If to be used for capturing, then it would have to be a "middle man" between the camera and the cRIO.
This would allow all of the processing to be done without putting ANY load on the cRIO. It would appear be something like a CMUCam to the cRIO.

The CMUCam would give the RC a very limited set of data (but the data was useful). It gave the centroid's (Center of mass) coordinates, 2 coordinates (a box where the green target was found), and servo control commands to keep the target centered.



You would need a hub or switch, not just a splitter.
Each camera would have its own IP address (unless your processing FPGA is what is ultimately communicating to the cRIO, in which case no cameras would show up, the only data transferred would be in your own custom protocol and with your own data.) and thus would show up as 2 cameras.

Thank you for your response, always good posts. Do you have any recommendations on the processors dedicated to process images? So would the cRio would treat the processor as a digital input?