Vision on separate board

[Noam787]

Hi everyone,

So, we were a rookie team last year and we didn't expect to have such high ping when using vision on the driver's computer. We are considering using a single board computer such as raspberry pi and we want to know if anyone had an experience using vision with single board computer and would recommend any board and\or what to consider when picking a board.

tnx GreenBlitz 4590#

[Bald & Bearded]

Last year we used a Pandaboard single board computer based on a white paper from another team. The two key issues you need to address no matter what you choose to use are:
1. Power - You will want to build voltage regulators to power the board off of the main power distribution board.
2. Communication - Spend a great deal of time defining how your vision program will communicate with the CRIO and other robot code. KISS principle applies as always. We also had the board streaming the image back to the DS so if you want to do that make sure you can control the bandwidth usage (resolution and Frames Per Second).

There are lots of good and cheap single board computers out there, I would just make sure you picked one which has a solid Linux build with all drivers available.

[ekapalka]

If your weight can afford it, I would recommend getting a used laptop computer (super cheap; maybe add an SSD). The power supply shouldn't be too difficult to figure out, and you'll probably be able to get more processing power. Of course, many teams have had success with Raspberry Pi's and other Linux compatible systems such as ODROID X2s or UDOOs (both have quad cores; worth looking at for vision processing). I can't believe you guys did vision processing your rookie year. You guys must have been pretty dedicated and organized :P

[faust1706]

I'd recommend using an O-droid product, that is, X-2, X, U-2, U. They are quad core, arm based, 1.7 GHz, much more powerful than the pi that may teams seem to use for some reason. As for talking with the cRio, we have been using a udp message.

[Noam787]

what specs of the board should i look for when picking one?

[protoserge]

Originally Posted by Noam787

what specs of the board should i look for when picking one?

I'd look for at least an ARM A9 dual core processor, RAM, Ethernet, USB Host, i2c running Linux and OpenCV. This has been well-documented and there are a lot of recent threads on this forum that you will find useful.

As mentioned before, the Odroid (www.hardkernel.com) is a good unit and I think it's one of the best specifications (quad core, etc). I think we will be getting one to experiment with. In the past, we have used one of the single core Mk801 Android PC units. We upgraded to a dual core Mk808, but never used it in competition.

I would not use an onboard laptop unless you absolutely have to - the size and weight concerns far outweigh the small cost of an ARM-based single board computer.

[ekapalka]

Originally Posted by Noam787

what specs of the board should i look for when picking one?

A fast multi-core CPU. ARM based boards or other small computers won't be capable of exploiting GPU for vision processing, so the CPU is pretty much all that matters. After that, I would look for something with USB 3.0 ports to accommodate higher end cameras (which you don't necessarily need, it's just a perk)

[Joe Ross]

There are two major issues that may cause latency when using vision on the driver station, bandwidth limit and driver station CPU throughput. Both can have an impact even when doing vision on a separate computer, so it would be helpful for you to determine which was causing your issue, so you can avoid it with your new architecture (or even get it working with the old architecture).

The bandwidth limit on the field is 7mbps. As the bandwidth used approaches that limit, the latency increases. There is very good data about this in the FMS Whitepaper. This only affects data sent over the radio, so if your vision processing is completely limited to your onboard computer, this won't be an issue. However, most likely you will want to have vision feedback on the driver station, therefore you will need to worry about bandwidth. One thing the whitepaper doesn't cover is that dark pictures compress much easier and also are easier to process. See http://www.chiefdelphi.com/forums/sh...2&postcount=44

The classmate PC only has an atom processor which can be overloaded with just displaying high resolution images. If the CPU is overloaded, it will also affect network latency. You can look at the driver station CPU usage on the charts tab of the driver station. Whether you do driver station or onboard vision processing, you will need to carefully manage CPU usage, as vision processing very quickly consumes all available CPU time. Limiting the rate at which vision processing occurs is smart no matter what platform you use. Again, if you send the processed images back to the driver station, you will need to worry about driver station CPU usage regardless of where the processing occurs, if you are using the classmate.

[Noam787]

Originally Posted by Joe Ross

There are two major issues that may cause latency when using vision on the driver station, bandwidth limit and driver station CPU throughput. Both can have an impact even when doing vision on a separate computer, so it would be helpful for you to determine which was causing your issue, so you can avoid it with your new architecture (or even get it working with the old architecture).

The bandwidth limit on the field is 7mbps. As the bandwidth used approaches that limit, the latency increases. There is very good data about this in the FMS Whitepaper. This only affects data sent over the radio, so if your vision processing is completely limited to your onboard computer, this won't be an issue. However, most likely you will want to have vision feedback on the driver station, therefore you will need to worry about bandwidth. One thing the whitepaper doesn't cover is that dark pictures compress much easier and also are easier to process. See http://www.chiefdelphi.com/forums/sh...2&postcount=44

The classmate PC only has an atom processor which can be overloaded with just displaying high resolution images. If the CPU is overloaded, it will also affect network latency. You can look at the driver station CPU usage on the charts tab of the driver station. Whether you do driver station or onboard vision processing, you will need to carefully manage CPU usage, as vision processing very quickly consumes all available CPU time. Limiting the rate at which vision processing occurs is smart no matter what platform you use. Again, if you send the processed images back to the driver station, you will need to worry about driver station CPU usage regardless of where the processing occurs, if you are using the classmate.

We actually used ours laptop it had an i7 CPU and 8GB of RAM more than enough to operate our image processing program. The problem was that we couldn’t compress the image because we used the camera almost only on the other side of the field and finding the goals required higher resolution image. But still I don’t know if the bandwidth is the problem because we took only one image to calculate the angle to turn. That’s why we want to try using a board to processes images

[Noam787]

Originally Posted by Joe Ross

There are two major issues that may cause latency when using vision on the driver station, bandwidth limit and driver station CPU throughput. Both can have an impact even when doing vision on a separate computer, so it would be helpful for you to determine which was causing your issue, so you can avoid it with your new architecture (or even get it working with the old architecture).

The bandwidth limit on the field is 7mbps. As the bandwidth used approaches that limit, the latency increases. There is very good data about this in the FMS Whitepaper. This only affects data sent over the radio, so if your vision processing is completely limited to your onboard computer, this won't be an issue. However, most likely you will want to have vision feedback on the driver station, therefore you will need to worry about bandwidth. One thing the whitepaper doesn't cover is that dark pictures compress much easier and also are easier to process. See http://www.chiefdelphi.com/forums/sh...2&postcount=44

The classmate PC only has an atom processor which can be overloaded with just displaying high resolution images. If the CPU is overloaded, it will also affect network latency. You can look at the driver station CPU usage on the charts tab of the driver station. Whether you do driver station or onboard vision processing, you will need to carefully manage CPU usage, as vision processing very quickly consumes all available CPU time. Limiting the rate at which vision processing occurs is smart no matter what platform you use. Again, if you send the processed images back to the driver station, you will need to worry about driver station CPU usage regardless of where the processing occurs, if you are using the classmate.

We actually used ours laptop it had an i7 CPU and 8GB of RAM more than enough to operate our image processing program. The problem was that we couldn’t compress the image because we used the camera almost only on the other side of the field and finding the goals required higher resolution image. But still I don’t know if the bandwidth is the problem because we took only one image to calculate the angle to turn. That’s why we want to try using a board to processes images.

[Noam787]

Originally Posted by Joe Ross

There are two major issues that may cause latency when using vision on the driver station, bandwidth limit and driver station CPU throughput. Both can have an impact even when doing vision on a separate computer, so it would be helpful for you to determine which was causing your issue, so you can avoid it with your new architecture (or even get it working with the old architecture).

The bandwidth limit on the field is 7mbps. As the bandwidth used approaches that limit, the latency increases. There is very good data about this in the FMS Whitepaper. This only affects data sent over the radio, so if your vision processing is completely limited to your onboard computer, this won't be an issue. However, most likely you will want to have vision feedback on the driver station, therefore you will need to worry about bandwidth. One thing the whitepaper doesn't cover is that dark pictures compress much easier and also are easier to process. See http://www.chiefdelphi.com/forums/sh...2&postcount=44

The classmate PC only has an atom processor which can be overloaded with just displaying high resolution images. If the CPU is overloaded, it will also affect network latency. You can look at the driver station CPU usage on the charts tab of the driver station. Whether you do driver station or onboard vision processing, you will need to carefully manage CPU usage, as vision processing very quickly consumes all available CPU time. Limiting the rate at which vision processing occurs is smart no matter what platform you use. Again, if you send the processed images back to the driver station, you will need to worry about driver station CPU usage regardless of where the processing occurs, if you are using the classmate.

We actually used ours laptop it had an i7 CPU and 8GB of RAM more than enough to operate our image processing program. The problem was that we couldn’t compress the image because we used the camera almost only on the other side of the field and finding the goals required higher resolution image. But still I don’t know if the bandwidth is the problem because we took only one image to calculate the angle to turn. That’s why we want to try using a board to processes images.

[Noam787]

We actually used ours laptop it had an i7 CPU and 8GB of RAM more than enough to operate our image processing program. The problem was that we couldn’t compress the image because we used the camera almost only on the other side of the field and finding the goals required higher resolution image. But still I don’t know if the bandwidth is the problem because we took only one image to calculate the angle to turn. That’s why we want to try using a board to processes images

[billbo911]

Originally Posted by Noam787

Hi everyone,

So, we were a rookie team last year and we didn't expect to have such high ping when using vision on the driver's computer. We are considering using a single board computer such as raspberry pi and we want to know if anyone had an experience using vision with single board computer and would recommend any board and\or what to consider when picking a board.

tnx GreenBlitz 4590#

Today and tomorrow, 2073 will be using a PCDuino and a MS USB Webcam onboard our robot at CalGames. It is running Ubuntu and OpenCV to do our target tracking. It passes off the corners and center positions of the top target to the cRio as a 24 character string over the local network on the robot. No WiFi bandwidth limitations at all.

This is the first time we have fully implemented this in competition. So, when they return, we will let you know how it performs.

[yash101]

I am also working on vision processing for our team. After finding out about the bandwidth limit restrictions, I decided it would be better to do all the work onboard the robot. I was loving the Pi, until, today, I found out about the odroid. Just made me nuts. The processor should be faster than my new i3 laptop! OpenCV might like running on the odroid. I find the Pi good for continuous applications requiring less power. However, I think the odroid will be more of the "performance," what is needed in a robot. Also, my Pi is oc'ed to 1.1GHz. Use a USB Camera to get away from network. Also, for some of these boards, you can use i2C instead of network, reducing network load and even making the system more robust.

[billbo911]

Originally Posted by billbo911

Today and tomorrow, 2073 will be using a PCDuino and a MS USB Webcam onboard our robot at CalGames. It is running Ubuntu and OpenCV to do our target tracking. It passes off the corners and center positions of the top target to the cRio as a 24 character string over the local network on the robot. No WiFi bandwidth limitations at all.

This is the first time we have fully implemented this in competition. So, when they return, we will let you know how it performs.

From all the reports I got back from the team, the camera tracking worked exactly as intended. The first half of the day we had great success with it.
But... later in the day, something in the robot went south. We lost all ability to drive. Luckily, we have zero indication it was related to the camera system in any way. Most likely we lost a DSC or possibly the PDB.

Either way, we are quite happy with the off-board vision processing.