Go Back   VEX Forum > Community > General Forum

General Forum Open Discussion of the VEX Robotics System that can be answered by anyone. VEX Robotics Engineers will not answer questions posted here; see Official VEX Technical Support below.

Reply
 
Thread Tools
  #11  
Old 02-13-2012, 09:15 PM
jpearman's Avatar
jpearman jpearman is offline
Senior Member
VEX # 8888
 
Join Date: Apr 2011
Location: Los Angeles
Posts: 3,208
Images: 2
Re: VEXpro - Communicating with external software

Quote:
Originally Posted by vexbot View Post
ERROR opening V4L interface
: No such file or directory
Child's result=256...awaiting child's termination...
Child's result=256.......starting child
Child's result=256...awaiting child's termination...
ERROR opening V4L interface
: No such file or directory
Child's result=256......starting child
ERROR opening V4L interface
: No such file or directory
Child's result=256...awaiting child's termination...
Child's result=256...awaiting child's termination...
This is telling you that V4L cannot be initialized. V4L is short for Video for Linux and is the mechanism that used to interface to your web cam. The home page here implies that your Logitech C210 is a supported camera so you should be good to go there.

I do not have a VEXpro so it's hard to debug this for you. However, the first thing we need to do is see if the camera driver is being loaded and a file in the /dev directory being created to access it.

The usage for the server is as follows (I could not run the server but can look at the source copy the usage function into test code to produce this).

Usage is: uvcslicesrvr [options]
Options:
-v Verbose (repeat for more verbosity)
-d<device> V4L2 Device(default: /dev/video0)
-l<logging_port> Logging port (default: 5006)
-p<port> Server port (default: 5005)
-x<width> Image Width(must be supported by device)(>960 activates YUYV capture) (default: 160)
-y<height> Image Height(must be supported by device)(>720 activates YUYV capture) (default: 120)
-c<command> Command to run after each image capture(executed as <command> <output_filename>)
-t<integer> Take continuous shots with <integer> seconds between them (0 for single shot)
-r Use read instead of mmap for image capture
-w Wait for capture command to finish before starting next capture
-m Toggles capture mode from YUYV to MJPEG capture
Camera Settings:
-B<integer> Brightness
-C<integer> Contrast
-S<integer> Saturation
-G<integer> Gain


This line

-d<device> V4L2 Device(default: /dev/video0)

is the line we are interested in, have a look in the /dev directory and see if there is a file named video0, be sure the camera is connected. If there is a different file but with a similar name then start the server using that as the device. For example, lets say you fine a file named "video12" then start the server as follows.

change directory to /opt/usr/bin (or whereever the server is)

cd /opt/usr/bin

then run the server

./uvcsrvr -d /dev/video12

Try this and let me know what you find out. I'm sure I could have this running fairly quickly but without the VEXpro in front of me it's hard to know if the drivers are being loaded correctly etc.

Edit:
Here is the code that is causing the error, /dev/video0 cannot be opened so the child process started from main exits.

Code:
  if ((vd->fd = open (vd->videodevice, O_RDWR)) == -1) {
    perror ("ERROR opening V4L interface \n");
    exit (1);
  }
Reply With Quote
  #12  
Old 02-14-2012, 12:52 AM
vexbot's Avatar
vexbot vexbot is offline
Senior Member
 
Join Date: Jul 2006
Location: Independence, Missouri
Posts: 383
Images: 6
Re: VEXpro - Communicating with external software

Quote:
Originally Posted by jpearman View Post
I do not have a VEXpro so it's hard to debug this for you. However, the first thing we need to do is see if the camera driver is being loaded and a file in the /dev directory being created to access it.

..... have a look in the /dev directory and see if there is a file named video0, be sure the camera is connected...

I just looked in the /dev directory and there wasn't any file named video. I unplugged the camera and plugged it back in, but when I refreshed the window, there still wasn't anything there.

Sorry, that was the one thing I forgot to check.

I looked on the internet earlier to see if I could any other information about the Logitech C210 webcam and I found a post on another website talking about a similar issue. They thought the webcam should work, but couldn't find any information to confirm whether or not it actually would. They found some information that said the Logitech C270 webcam should work and confirmed that it did. Now, I'm wondering if I should try it instead. I bought my C210 at Radio Shack last Friday so I still have time to return or exchange it and they do have the C270. As a matter of fact, it was one of the webcams I considered buying.

I looked on the internet before I bought the webcam just to see if I could find out which ones would work with Linux and both the C210 and C270 were on the list. I choose the C210 because it was just a basic webcam and I figured the simpler the better chance of working.
__________________
Allen

A former VEX Robotics Hobbyist
I miss it everyday!

Last edited by vexbot; 02-14-2012 at 01:01 AM. Reason: Wanted to add some more information
Reply With Quote
  #13  
Old 02-14-2012, 12:00 PM
jpearman's Avatar
jpearman jpearman is offline
Senior Member
VEX # 8888
 
Join Date: Apr 2011
Location: Los Angeles
Posts: 3,208
Images: 2
Re: VEXpro - Communicating with external software

You can check if the webcam is at least being detected on the USB bus by using the lsusb command. This should be available, I took a quick look at the default file list that Quazar posted and I see it in sbin. I also see the video drivers there.
Reply With Quote
  #14  
Old 02-15-2012, 06:03 PM
vexbot's Avatar
vexbot vexbot is offline
Senior Member
 
Join Date: Jul 2006
Location: Independence, Missouri
Posts: 383
Images: 6
Re: VEXpro - Communicating with external software

OK, I just checked and the camera is being detected by the usb port. Here's a copy from the terminal window:

Code:
root@qwerk:~# lsusb
Bus 001 Device 001: ID 1d6b:0001  
Bus 001 Device 002: ID 046d:0819 Logitech, Inc. 
Bus 001 Device 003: ID 148f:2573 Ralink Technology, Corp. 
root@qwerk:~#


There still isn't any video file in the dev directory. Where should I go from here - any ideas?
__________________
Allen

A former VEX Robotics Hobbyist
I miss it everyday!
Reply With Quote
  #15  
Old 02-17-2012, 03:00 PM
vexbot's Avatar
vexbot vexbot is offline
Senior Member
 
Join Date: Jul 2006
Location: Independence, Missouri
Posts: 383
Images: 6
Smile Re: VEXpro - Communicating with external software

Just an update.

The streaming video part finally works! I went back to Radio Shack yesterday and purchased a different webcam (a Microsoft Lifecam HD-3000) and tried it out last night. I checked using "lsusb" and it was listed and there was a video file in the "dev" folder. I received the “waiting for video client connection on port 5005” message in the "console" window of the TerkIDE and ran the Java Jar file.

Now, I just have to make the image bigger and get it working with the RoboRealm software. There is a java file "RR_API.java" that I was able to look at that I think is the part I need, but I keep getting the same error when I try to run it as when I tried to run the Jar file. I know I need to try the eclipseIDE for Java that jpearman suggested in an earlier post and somehow make an exacutable file that I can run.

Any advice on this part besides what's already been mentioned?
__________________
Allen

A former VEX Robotics Hobbyist
I miss it everyday!
Reply With Quote
  #16  
Old 02-17-2012, 03:24 PM
jpearman's Avatar
jpearman jpearman is offline
Senior Member
VEX # 8888
 
Join Date: Apr 2011
Location: Los Angeles
Posts: 3,208
Images: 2
Re: VEXpro - Communicating with external software

Well thats good news, sorry I had not got back to you but I was out of ideas and didn't really know what to try next. When I plugged a web cam into a Fedora linux install I have (don't use linux much) everything had worked as advertised.

You should be able to increase the size by using different arguments to the server and client. The default is 160 x 120 so start the server with the following additional args.

./uvcsrvr -x 320 -y240

The usage from the java client source code is


Code:
String usage = 
"Usage: \n"+
"  roombacomm.Roborama --videoServer <IP> --videoPortNum <port> -x <image X size> -y <image Y size>[options]\n" +
"where [options] can be one or more of:\n"+
" -X | --debug       -- turn on debug output\n"+
" -x <width> or --width <width>: set width\n" +
" -y <height> or --height <height> -- set height\n" +
" -c | --color -- use color mode, otherwise grayscale\n" +
" --videoserver <IP> : set IP address of video server\n" +
" --videoPortNum <port> : set port number on video server\n" +
" -t | --threshold <threshold> : set quantization threshold\n" +
" -R | --RoboRealm : connect to Roborealm & send image to it. Roborealm requires color\n" +
" -hwhandshake -- use hardware-handshaking, for Windows Bluetooth\n";
so do the same thing there as well

java -jar watchVideo.jar --videoServer 192.168.0.99 -x320 -y240

There is also a --RoboRealm argument for connecting to the RoboRealm software.

Last edited by jpearman; 02-18-2012 at 12:15 AM. Reason: typo
Reply With Quote
  #17  
Old 02-17-2012, 11:40 PM
vexbot's Avatar
vexbot vexbot is offline
Senior Member
 
Join Date: Jul 2006
Location: Independence, Missouri
Posts: 383
Images: 6
Re: VEXpro - Communicating with external software

Quote:
Originally Posted by jpearman View Post
Well thats good news, sorry I had not got back to you but I was out of ideas and didn't really know what to try next. When I plugged a web cam into a Fedora linux install I have (don't use linux much) everything had worked as advertised.

You should be able to increase the size by using different arguments arguments to the server and client. The default is 160 x 120 so start the server with the following additional args.

./uvcsrvr -x 320 -y240

The usage from the java client source code is


Code:
String usage = 
"Usage: \n"+
"  roombacomm.Roborama --videoServer <IP> --videoPortNum <port> -x <image X size> -y <image Y size>[options]\n" +
"where [options] can be one or more of:\n"+
" -X | --debug       -- turn on debug output\n"+
" -x <width> or --width <width>: set width\n" +
" -y <height> or --height <height> -- set height\n" +
" -c | --color -- use color mode, otherwise grayscale\n" +
" --videoserver <IP> : set IP address of video server\n" +
" --videoPortNum <port> : set port number on video server\n" +
" -t | --threshold <threshold> : set quantization threshold\n" +
" -R | --RoboRealm : connect to Roborealm & send image to it. Roborealm requires color\n" +
" -hwhandshake -- use hardware-handshaking, for Windows Bluetooth\n";
so do the same thing there as well

java -jar watchVideo.jar --videoServer 192.168.0.99 -x320 -y240

There is also a --RoboRealm argument for connecting to the RoboRealm software.
That's OK, I didn't know what else to do either except to try a different camera. I don't why the Logitech camera didn't work, but the Microsoft camera works great!

I have to appologize again for not looking into things more before posting. I found out the same things you mentioned above after I played around after dinner. I took some time to actually look at the java files. I'm just not used to this - I'm used to loading the software and running it with any options being available from a menu.

Anyway, I was able to connect with RoboRealm and display the video from the camera. I just wasn't able to make the image bigger. I was only trying it with the file on my pc and I wasn't sure if I actually needed the "x" and "y" or not. I never went back to try it with them.

Now, I'm trying to figure out how variables get passed back and forth and how I would get one from the java app into my program to control the robot. I looked at the "RR_API.java" file and I found the code for sending and receiving variables - I'm just not sure how it works. I copied it into a WORD file that I attached to this post. That code begins about the middle of page 10. I'm going to keep trying to figure it out, but if you wouldn't mind taking a look at it too, I would appreciate it. Hopefully, you will be able to give me some advice or at least help me understand it.

Thanks again for all of your help so far, I really do appreciate it. All of this is new to me and is probably why it says the VEXpro is for advanced users. Although, it really isn't that hard - it's just knowing what to do and how to do it.
Attached Files
File Type: zip RR_API.zip (42.4 KB, 54 views)
__________________
Allen

A former VEX Robotics Hobbyist
I miss it everyday!
Reply With Quote
  #18  
Old 02-18-2012, 12:36 AM
jpearman's Avatar
jpearman jpearman is offline
Senior Member
VEX # 8888
 
Join Date: Apr 2011
Location: Los Angeles
Posts: 3,208
Images: 2
Re: VEXpro - Communicating with external software

Quote:
Originally Posted by vexbot View Post
Now, I'm trying to figure out how variables get passed back and forth and how I would get one from the java app into my program to control the robot. I looked at the "RR_API.java" file and I found the code for sending and receiving variables - I'm just not sure how it works. I copied it into a WORD file that I attached to this post. That code begins about the middle of page 10. I'm going to keep trying to figure it out, but if you wouldn't mind taking a look at it too, I would appreciate it. Hopefully, you will be able to give me some advice or at least help me understand it.
There are two communication paths

1. from the java client to the sever on the VEXpro
2. from the java client to RoboRealm

The code you posted is part of the second case, I think what you really want is the first. Take a look at the server code in uvccapture.c

This is where the server accepts connections and starts a new thread for the client messages. (around line 245)

Code:
	// wait for a video client to connect before proceeding
	fprintf (stderr, "waiting for video client connection on port %d\n", port);
	if ((ctrl.videoSocket = wait4client(port)) <= 0) {
		fprintf (stderr, "error connecting to client: %d\n", ctrl.videoSocket);
		exit(-1);
	}
	// start the thread that handles the video client requests
	pthread_create(&videoSocketThread, NULL, (void *)cmdHandler, (void *)&ctrl);
This is the code that is running in the thread.

Code:
/* handle commands from RoombaComm client as long as the socket stays open */
void
cmdHandler(ctrlStruct * ctrl)
{
	unsigned char clientCmd[256];
	int rv;
	int netInt;

	while (run) {
		//fprintf (stderr, "waiting for command from client\n");
		rv = read(ctrl->videoSocket, &clientCmd, 10);
		if (rv < 0) {
			perror("socket read: ");
			exit(-1);
		}
		if (verbose > 1) fprintf (stderr, "received command %d\n", clientCmd[0]);

		if (clientCmd[0] == 200)
			outputType = 0;		// grayscale output
		else if (clientCmd[0] == 201)
			outputType = 1;		// rgb output

		ctrl->doCapture = 1;	// tell startvideoserver() to capture a snapshot
		if (verbose > 1) fprintf (stderr, "waiting for capture to complete");

		while (ctrl->doCapture == 1) {
			fprintf (stderr, ".");
			usleep(50000);
		}

		if (verbose > 2) fprintf (stderr, "writing %d image bytes to socket, width %d height %d, pixelCnt %d\n", ctrl->imgLength, ctrl->imgWidth, ctrl->imgHeight, ctrl->pixelCnt);

		// convert size variables to network byte order
		netInt = htonl(ctrl->imgWidth);
		write (ctrl->videoSocket, &netInt, 4);
		netInt = htonl(ctrl->imgHeight);
		write (ctrl->videoSocket, &netInt, 4);
		netInt = htonl(ctrl->imgLength);
		write (ctrl->videoSocket, &netInt, 4);
		write (ctrl->videoSocket, ctrl->imgArray, ctrl->imgLength);
		if (verbose > 2) fprintf (stderr, "wrote image & params\n");
	}
}
You can see it handles two different messages, the byte stored in clientCmd[0]. You probably need to modify this first and then start working to modify this code at the java end (from FrameProcessor.java)

Code:
public int readFrame(int width, int height, int captureType)
	{
		int bytesPerPixel = 1;
		int readLength = 0;
		int rxImageSize;
		int rgbShiftSize = 16;
		int pixel = 255 << 24;
		
		if (captureType == 1)	// if rgb color, 3 bytes/pixel, otherwise 1 byte/pixel for grayscale
			bytesPerPixel = 3;
		frameSize = width * height * bytesPerPixel;
		
		int maxReadSize = frameSize;
		readBuf = new byte[frameSize];			// analysis form - temp buffer for raw received data
		vidBuf = new byte[frameSize];			// raw image bytes
		vidDispBuf = new int[frameSize];		// display version (alpha set, bytes replicated if needed)
		int vidDispBufIx = 0;
		int vidBufIx = 0;
		
		readBuf[0] = (byte)(200 + captureType);	// send the "capture" command
		byte[] t = new byte[4];
		
		try {
			out.write(readBuf, 0, 1);
			out.flush();
None of this is simple, it may be better to start with your own version of the java client. If I were doing this I would rewrite the java code in one of my preferred development tools.
Reply With Quote
  #19  
Old 04-28-2012, 11:27 PM
bouchier's Avatar
bouchier bouchier is offline
Junior Member
 
Join Date: Nov 2011
Location: Dallas, TX
Posts: 7
Re: VEXpro - Communicating with external software

Hey guys - sorry for being so late to this thread. Blackstag just pointed me to it. Allen - I hope you had some success. I wrote the article you refer to, and the code, and if I can help I will. It's good to hear someone's looking at this stuff - I thought all that writing & coding was going into a black hole.

Here's some overview information. I'm sorry the documentation in the article wasn't better - they limit you to about 3000 words, and you have to try & get the central themes over, and give the technical details & build instructions in online docs linked from the article. If I don't reply to this thread (I'm not sure it emails me when someone posts) you can email me a paul.bouchier at gmail

The video on vexpro app is based on code I've been running on Chumby & Vexpro for a long time. I've integrated the java code with Chumby & Roborealm & it works great - there shouldn't be problems with vexpro - in fact I'm going to do that for Roborama 2012a in the next couple of weeks. If you look at this video: http://youtu.be/7X4E3_YwghM you'll see a mower (the silver/grey one) that uses odometry to get close to the cone, then switches to visual seeking, where it captures a frame from the webcam on Chumby, ships it back to roombacommcli, which sends it to Roborealm and reads back the location of the cone if Roborealm could find it. roombacommcli then tells the robot what to do. Same scheme should work with Vexpro - it just uses standard Linux capabilities.

The overall application architecture is a java app running on my laptop under eclipse, Roborealm running on the laptop, and a derivative of uvcserver running on Chumby/Vexpro. I use the TerkIDE to develop for vexpro, but it doesn't let you specify arguments on the command line so when I'm trying stuff out I ssh into vexpro & run the binary with command-line arguments, then set them as the default when I want to debug with Terk IDE.

For the robotic motion application, I start Roborealm first, (must enable the socket on Roborealm so it accepts connections from the java app. Then I start the daemon on Chumby or Vexpro which opens the webcam and listens on a socket for requests from roombacommcli to capature a video frame. Then I start a 2nd app on Chumby/Vexpro which listens for motion requests from roombacommcli. The java app on the PC (roombacommcli) runs the robot to the point where video seeking should start, then stops the robot (so video is sharp), requests the daemon on the robot to capture a frame & send it back. When the frame arrives back at the java app it sends it to Roborealm using the java library RR_API, which formats the request as an XML document & sends it over a socket to Roborealm. Roborealm is configured with a series of filters (filter for red, improve image, do shape recognition), and sends the X & Y coordinates of the shape (if found) back over the socket to the java app (roombacommcli). Depending on whether Roborealm found the cone, the java app commands the robot to spin a little, then looks again, or seeks toward it. Most of the interesting java code that does this on the PC is in an app called roombacommcli. (Despite its name it will run a roomba, Mo'bot the mower, and tankbot.) Watchvideo is a limited version of roombacommcli that only displays video - it doesn't run the robot. I haven't actually tried connecting watchvideo to Roborealm outside of roombacommcli.

Looking at the error message you're getting on vexpro, I'd say the uvcsrvr app on Vexpro isn't finding the webcam. Try:
% ls /dev/video0
(This is like DIR on windows.) The app expects your webcam to be at /dev/video0. You can override that with command-line options.

I suggest you attack this incrementally. 1st, get the uvcsrvr daemon to connect to the webcam successfully. Critical points will be the device name (/dev/video0), and whether it uses YUYV or some other video format. Then get the watchvideo app working on the PC and connecting to uvcsrvr on vexpro. You'll see output on vexpro as it sends each frame to the PC. The video X & Y size has to match between the two apps. You should get about 3 frames/sec.

regards

Paul
Reply With Quote
  #20  
Old 04-29-2012, 10:54 AM
bouchier's Avatar
bouchier bouchier is offline
Junior Member
 
Join Date: Nov 2011
Location: Dallas, TX
Posts: 7
Re: VEXpro - Communicating with external software

Oops - didn't realize there was a 2nd page of discussion on this. That really makes me feel good! jpearman and quazar have really dug in & understood this system. Glad you got the video going Allen. Let me know if you need further help. As I said, I haven't tried connecting the watchvideo system up to Roborealm but it should be straightforward. If it doesn't "just work", I can fix it so it does.

Just FYI - the watchvideo system & the roombacommcli system it's part of is an unsatisfactory architecture. The latency over TCP/IP is too long to do good robot control. I'm moving to a subsumption based architecture. An implementation of subsumption which runs on Vexpro is available from the DPRG svn server here:
http://svn.dprg.org/repos/dprg/VEXPr...k/roombaVEXPro

Here's an excellent, and very readable introduction to subsumption, on which my subsumption implementation is based, written by David Anderson - one of the DPRGs preeminent roboticists:
http://www.geology.smu.edu/~dpa-www/robo/subsumption/

It runs a roomba, but doesn't have the video logic or Roborealm connection you want. It should be readily modifiable for other robots - I'm going to generalize it to run Mo'bot (the lawnmower). But first I'm fixing to tie it into uvcsrvr and have uvcsrvr talk to Roborealm directly, which is what you're really looking for. Having the robot control running on the robot will give it much better responsiveness to object collisions, better tracking of current location based on odometry, etc, while keeping video processing offloaded to the PC.

Paul
Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -6. The time now is 02:41 AM.


VEX and VEX Robotics are trademarks or service marks of Innovation First International, Inc.
Copyright © 2002-2013. All Rights Reserved. VEX Robotics, Inc. is a subsidiary of Innovation First International, Inc.
All other product names/marks of others are the property of their respective owners.