Connecting a USB camera to Speedgoat

Our aim is to use a high speed camera connected through CameraLink interface in the future. For the first attempts with video, we used a USB2.0 webcam.

Choosing the camera

We were looking for some friendly-priced camera with full resolution around 2Mpx at framerate 30 fps. Another criterion was the possibility to set the parameters of the camera (white balance, exposure time, etc.) manually.

When choosing the camera, we had to be aware that the manufacturers always present the highest resolution and highest framerate at once, but they often omit the fact that the highest resolution is not available at the highest framerate.

Finally, we have chosen Creative Live! Cam Socialize HD 1080. For a reasonable price (around 1300CZK), it offers capturing video sequences in full-HD resolution 1920x1080 at framerates up to 30 fps. The parameters of the camera can be set manually (through software). In addition, the camera has glass lens, which is another advantage compared to cheaper models that are often provided with plastic optics.

Experience with USB camera on Speedgoat

Speedgoat offers in fact a 'plug-and-play' use of the USB camera. You only need to know which blocks to put in the Simulink model and interconnect them correctly to start capturing the video.

1. boot Speedgoat
2. plug-in the USB camera
3. connect to Speedgoat from the host PC using the xPC Explorer
4. open your Simulink model and choose preferred camera configuration
5. you can start the video capture by running the model

Be sure not to plug-in the camera until the target machine has booted. If the target machine detects a USB device connected when you turn it on, it tries to boot from it as if it was a USB stick.

We tried to transmit the video to the host PC over the Ethernet cable, but the transmission does not work very well. Even though the camera is capturing frames at 30 Hz, the resulting effective framerate on the host PC is around 3 Hz. The capture rate was checked by an xPC Target Scope connected to a single image pixel, through which we could observe the time intervals between changes of the pixel's intensity value. We did not find any error in our model nor any other working solution on the web. The problem might be that the communication between the target and host PC during the execution of the target application generates so heavy network traffic that the video frames which are transmitted via UDP get lost. A possible solution could be to build a standalone target application to eliminate the host-target communication during execution and only use the Ethernet for video transmission. However, one needs an xPC Target Embedded Option licence to build standalone target applications, so we could not verify this hypothesis.