from Paulene Purdy to willu@cse.unsw.edu.au cc renner@ecst.csuchico.edu, "Dr. J" date Feb 6, 2007 11:54 AM subject rUNSWift Robot Soccer mailed-by gmail.com Dr. Uther, I am a student at California State University, Chico. We chose the 2005 UNSW robot soccer code to work with in our Intelligent Systems Lab because we found the code easier to work with than some, it was already integrated with the GameController, and we really liked the use of Indicators. Currently, when the dogs are in "play" mode they spin in circles without stopping. According to the Behavior Thesis I read, this is expected behavior when the dog cannot find the ball. I also read the Vision Thesis by Alex North. It indicates that we are to generate a 2MB color table. How do we go about generating this file? Are there other things we have to do to calibrate the dogs? Do you have any documentation that might be helpful to us? If you cannot answer my questions, can you direct me to someone who can? Regards, Paulene M. Purdy ---------- from William Uther to Paulene Purdy cc renner@ecst.csuchico.edu, "Dr. J" date Feb 6, 2007 2:59 PM subject Re: rUNSWift Robot Soccer mailed-by cse.unsw.edu.au Hi, I've forwarded your mail to a mailing list which the students read. I hope one of them gets back to you soon. If not, bug me again and I'll see what I can do. Good luck, Will :-} ---------- from Andrew Million S to paulenepurdy@gmail.com cc willu@cse.unsw.edu.au, robocup.2005@cse.unsw.edu.au date Feb 8, 2007 7:31 PM subject Re: rUNSWift Robot Soccer mailed-by gmail.com Hi Paulene, "spin in circles without stopping" Yes, it would keep trying to find the ball in play mode. If the ball already being placed in the field, then you could be right, it needs some calibration. If I remember correctly, we used RDR tool in the base/colour directory to calibrate the colours. On top of my head, steps: 1. Take a lot of photos with ball in it. (using the dogs of course... ) 2. Use the colour calibration tool (base/colour/ic ..) 3. Use the tool to manually calibrate the range of each colour. 4. copy the nmc to robot\cfg 5. make More detail on calibration, can be read in 2003 thesis document. Regards, A Million --------- from Alex North to paulenepurdy@gmail.com cc William Uther , renner@ecst.csuchico.edu, Juliano@csuchico.edu date Feb 9, 2007 3:24 PM subject Re: Fwd: rUNSWift Robot Soccer mailed-by cse.unsw.edu.au Hi Paulene, I'm sorry for the slow response - I've been meaning to dig out the code and find out for you. Everything you've said is right. To generate the colour table there are a number of tools under the base/ directory. The one we used for the competition is /trunk/base/colour/rc/ It loads images, lets you classify colour regions, and can save an nnmc.cal lookup table. You need to load a bunch of BFL image files into it. I think there might be a photo-taking behaviour file you can load onto the robot, which takes a photo when you touch its head. We usually got them remotely though. Run to program under trunk/base/robolink/ - it acts as a multiplexing gateway between applications on your machine and data providers on the robot. Run the tool in /trunk/base/subvision/ and instruct it to receive data from your local robolink. Then if I recall correctly you need to run SimpleRoboCommander, which has a button somewhere to instruct to robot to take a picture and send it back via robolink. I can't quite remember, but you may need to run trunk/base/client/ to help SimpleRoboCommander communicate with the robot. Phew! There's a lot of details I'm skipping or have forgotten - I haven't looked at the code for about 18 months. I'm sorry it's not more of a one-click operation. Under the pressure of the competition there wasn't a lot of motivation to make things easy to use if they were "easy enough". Feel free to contact me directly if you have any further questions. Cheers, Alex ------------ from Paulene Purdy to Alex North cc "Dr. Renner" , "Dr. J" date Feb 14, 2007 5:54 PM subject Re: Fwd: rUNSWift Robot Soccer mailed-by gmail.com Hi Alex, Thanks for replying. I have some questions: What is the difference between ic & rc? Andrew Million pointed me to use ic and you told me to use rc. Are these the two approaches to table generation you refer to in your thesis? (RDR & Weighted Kernel Classifcation) Which one is which? Does ic/rc correct the chromatic distortion or is there yet something else I need to do? There are a lot of directories under base that I don't know what they're used for. What pieces do I really need to worry about? Are there any READMEs other than those in the codebase? I seem to be at a loss for where to start. The thesis papers, although interesting from a high level or theoretical point of view, do not give any how-to kind of instructions. Do you have to install the behavior file to gather *remote* pictures? I'm assuming that the behavior file is a Python file used as input to the spip script--is that the case? I've tried looking for it, but I can't find it. What would it be called? So, Andrew said I should take the nnmc.cal file that is the output of ic and stick it in the robot/cfg directory. What about the nnmc.cal file that is created during the build from the tightnnmc.cal & loosennmc.cal files? Should I be producing these files instead? If so, what different technique would I use to produce each of these? I looked at SimpleRoboCommander. It seems to be python code. The Makefile in the directory cd's into CPlaneClient to build, but there is no Makefile there. Are you speaking of this "client"? Or are you talking about base/client? I ran base/client to get the usage. I'm *really* confused now. What I really need is a quick README for the base directory that defines what each of the directories in base is. I also need some step-by-step instructions for producing this color table like "Run this program by typing this command, click on these things, run this program by typing this command,..." etc. This will allow me to run the programs in the correct order and tell me what I'm trying to do. I don't expect a huge document, just a README that allows new programmers for the project to get going. Could you do this for me? Or is there someone who could? In case you don't want to download the codebase and browse through it. Attached is a quick find on the 2005 codebase. Thanks, Paulene ---------- from Paulene Purdy to robocup.2005@cse.unsw.edu.au date Feb 19, 2007 2:18 PM subject Fwd: Fwd: rUNSWift Robot Soccer mailed-by gmail.com Here's an email I recently sent to Alex. I haven't received a response yet. Please note that I've used qmake to generate a Makefile for subvision. So, all of the programs that Alex has mentioned run now. But, I'm not sure how to run them together. I did the following: ./robolink (in base/robolink) ./SubVision (in base/subvision), then I use File->Connect to localhost:9000, then robolink seems to see the client ./ClientServer.py (in base/SimpleRoboCommander). The SimpleRoboCommander prompts me to listen on an ip and port. I'm not sure what to put here. Now where is the button to send the command to take a picture? Where/when do I run base/client? When I run ./client r (from base/client), SimpleRoboCommander says "New Client" 4 times. Is this all connected properly? Could you explain what each one of these programs is doing? Here are my remaining questions: *What is the difference between ic & rc? Andrew Million pointed me to use ic and you told me to use rc. Are these the two approaches to table generation you refer to in your thesis? (RDR & Weighted Kernel Classifcation) Which one is which? Does ic/rc correct the chromatic distortion or is there yet something else I need to do? *Do you have to install the behavior file to gather *remote* pictures? I'm assuming that the behavior file is a Python file used as input to the spip script--is that the case? I've tried looking for it, but I can't find it. What would it be called? *So, Andrew said I should take the nnmc.cal file that is the output of ic and stick it in the robot/cfg directory. What about the nnmc.cal file that is created during the build from the tightnnmc.cal & loosennmc.cal files? Should I be producing these files instead? If so, what different technique would I use to produce each of these? Thanks, Paulene --------- from Alex North to Paulene Purdy cc robocup.2005@cse.unsw.edu.au date Feb 19, 2007 2:49 PM subject Re: Fwd: Fwd: rUNSWift Robot Soccer mailed-by cse.unsw.edu.au Argh, so sorry. Thanks for reminding me. Some answers below, and I'll get back to your previous email too. On 20/02/2007 9:18 AM, Paulene Purdy wrote: > Here's an email I recently sent to Alex. > ... > I did the following: > ./robolink (in base/robolink) > ./SubVision (in base/subvision), then I use File->Connect to > localhost:9000, then robolink seems to see the client > ./ClientServer.py (in base/SimpleRoboCommander). The > SimpleRoboCommander prompts me to listen on an ip and port. I'm not > sure what to put here. Now where is the button to send the command to > take a picture? I'm not quite sure either, I don't remember this. I'm pretty sure it's a port to listen on for a connection from client. localhost:5005 would be my guess, but you might need to investigate a little. | ] CPlane | | | | AIBO [ <- client -> ] SimpleRoboCommander | | | | | ] World Model The send picture button will be labelled something like "Send YUV". > Where/when do I run base/client? When I run ./client r (from > base/client), SimpleRoboCommander says "New Client" 4 times. Is this > all connected properly? That sounds ok. You need to specify the robot ip suffixes for it to connect to if there is no conf.cfg. Usage: client [vhrcygdf] [[IP_postfix_1] [IP_postfix_2] ...] first argument are commands enabling sockets (except 'v'): v = verbose mode h = humanControl (local port: 5102) r = roboCommander (5005) c = cplane (5010) y = yuvPlane (5011) g = grapher (5014) d = debug (5015) f = frameRate (5006) if no IP postfix is specified, they will be read from 'conf.cfg'. > Could you explain what each one of these programs is doing? Robolink connects to the robot and receives data streams, including the YUV photo. Subvision connects to robolink and does something (shows you the photo) when the dog sends data. Client is a muliplexer between control applications like SimpleRoboCommander and one or more robots. > Here are my remaining questions: > > *What is the difference between ic & rc? Andrew Million pointed me to > use ic and you told me to use rc. Are these the two approaches to table > generation you refer to in your thesis? (RDR & Weighted Kernel > Classifcation) Which one is which? Does ic/rc correct the chromatic > distortion or is there yet something else I need to do? ic is old and very manual. Don't use it; use RC instead. Neither correct chromatic distortion. This distortion is corrected by hardcoded constants in dogParams.cc. These constants are generated by programs in base/colour/linearShifts, but I have no experience with them. > *Do you have to install the behavior file to gather *remote* pictures? > I'm assuming that the behavior file is a Python file used as input to > the spip script--is that the case? I've tried looking for it, but I > can't find it. What would it be called? I think using SimpleRoboCommander as a remote control you can gather pictures using any behaviour. Get the dog up and running using the pDoNothing behaviour (so it stands still) then use the remote control. There is a behaviour which takes photos when you touch the head button and either saves them to MS or sends them over robolink (can't remember which): pPhotoTaker.py > *So, Andrew said I should take the nnmc.cal file that is the output of > ic and stick it in the robot/cfg directory. What about the nnmc.cal > file that is created during the build from the tightnnmc.cal & > loosennmc.cal files? Should I be producing these files instead? If so, > what different technique would I use to produce each of these? Ah. The makefile builds nnmc.cal from tightnnmc.cal and loosennmc.cal. They all have the same format so you'll be ok if you just replace nnmc.cal (but beware of Make overwriting it). They're produced by the same programs. tightnnmc.cal is a "tight" classification in that pixels are only classified if you're *really sure* they're not going to appear as another colour when playing. E.g. pink and orange are close, so the tight calibration only classifies the core regions of each. This is a pretty fine detail though, don't worry about it yet. ---------- from Alex North to Paulene Purdy cc Andy Owen date Feb 19, 2007 3:07 PM subject Re: Fwd: rUNSWift Robot Soccer mailed-by cse.unsw.edu.au Again, sorry for my slowness. On 15/02/2007 12:54 PM, Paulene Purdy wrote: > There are a lot of directories under base that I don't know what they're > used for. What pieces do I really need to worry about? Are there any > READMEs other than those in the codebase? I seem to be at a loss for > where to start. The thesis papers, although interesting from a high > level or theoretical point of view, do not give any how-to kind of > instructions. A lot of them are old stuff used by previous teams, which we haven't removed in case they contain something useful. I think you've mentioned all the important ones: SimpleRoboCommander, client, colour, robolink. Others that have useful but non-essential stuff include worldviewer (a sniffer on team communication), walkBase (walk optimisation), debugging (crash dump analysis). > Do you have to install the behavior file to gather *remote* pictures? > I'm assuming that the behavior file is a Python file used as input to > the spip script--is that the case? I've tried looking for it, but I > can't find it. What would it be called? pPhotoTaker takes pictures with the head button, but I'm pretty sure any will take pictures via remote control. > I looked at SimpleRoboCommander. It seems to be python code. The > Makefile in the directory cd's into CPlaneClient to build, but there is > no Makefile there. Are you speaking of this "client"? Or are you > talking about base/client? I ran base/client to get the usage. I'm > *really* confused now. Sorry, qmake for most of our guis. Both SimpleRoboCommander and client are used (I use "client" as a proper noun - the program is rather unfortunately named). > What I really need is a quick README for the base directory that defines > what each of the directories in base is. I also need some step-by-step > instructions for producing this color table like "Run this program by > typing this command, click on these things, run this program by typing > this command,..." etc. This will allow me to run the programs in the > correct order and tell me what I'm trying to do. I don't expect a huge > document, just a README that allows new programmers for the project to > get going. Could you do this for me? Or is there someone who could? Sorry, I don't have time to do a README for you (I'm not at uni any more). Most of the 2005 team members will have forgotten everything by now - I'd be figuring it out from scratch nearly as much as you would. Andy Owen from the 2006 team might have a less sketchy memory. For colour classification with rc (from memory): * load up some BFL files (there's a yuv2bfl program somewhere to create BFLs from YUV photos) * select a photo, select a colour, click on pixels that should be classified that colour * repeat * "save nnmc" writes an nnmc.cal file Alex --------- from Andrew Million S to Paulene Purdy cc alexn@cse.unsw.edu.au, robocup.2005@cse.unsw.edu.au date Feb 19, 2007 3:37 PM subject Re: Fwd: rUNSWift Robot Soccer mailed-by gmail.com Hi Paulene, Alex definitely know better than me, Alex didn't CC email to me so I don't know what's happening, information that I gave was on top of my head. You would have much better chance following Alex's instructions, because he is the best person on this. PS: Alex, how are you doing ? How come you still have cse email address ? Regards, A Million --------- from Andy Owen to Alex North cc paulenepurdy@gmail.com date Feb 20, 2007 12:32 AM subject Re: Fwd: rUNSWift Robot Soccer > > I looked at SimpleRoboCommander. It seems to be python code. The > > Makefile in the directory cd's into CPlaneClient to build, but there is > > no Makefile there. Are you speaking of this "client"? Or are you > > talking about base/client? I ran base/client to get the usage. I'm > > *really* confused now. > > Sorry, qmake for most of our guis. Both SimpleRoboCommander and client > are used (I use "client" as a proper noun - the program is rather > unfortunately named). I've never used SimpleRoboCommander or CPlaneClient, so I can't help much with them, except to say that you don't need them. > > > What I really need is a quick README for the base directory that defines > > what each of the directories in base is. I also need some step-by-step > > instructions for producing this color table like "Run this program by > > typing this command, click on these things, run this program by typing > > this command,..." etc. This will allow me to run the programs in the > > correct order and tell me what I'm trying to do. I don't expect a huge > > document, just a README that allows new programmers for the project to > > get going. Could you do this for me? Or is there someone who could? You need 3 programs. offvision, robolink and senddata. offvision is written in C++, and can be compiled with qmake then make. robolink is C I think, and probably has a make file. senddata I can't remember, but it probably has a make file too. You need a stick with any runswift behaviour on it ("ins 142 pDoNothing" at a prompt should do this assuming you have your path set up, the IP address will be 192.168.0.142, so you might need to change some magic somewhere if that isn't good for you, I seem to remember someone getting angry that the prefix was mentioned in more than one spot so watch out) Then, once the robot has booted type: robolink 142 filename.rlog (if you leave out the filename then it will output to log.rlog and it will always overwrite without warning) It will tell you which port to connect to, if you are only connecting to one dog, then you can ignore this. Once it has connected, robolink will tell you whenever it receives a packet. At the moment, it won't be receiving anything so not much will go on. To get stuff sent to you, use senddata. senddata 142 21 I think will send you camera images every so-many frames. Once it is sending stuff, you can open up offvision and connect to the dog (File->Connect, type the IP address, the default port should be good). A ((fairly large) finite) buffer of the live stream will be stored in memory, so you can rewind and pause and stuff like that. Alternatively, you can open an rlog file, or a BFL file (a single image, taken using pPhotoTaker) if you are doing stuff offline. The far right tab in offvision lets you make colour calibration files. There are two files you work with: *.kernel files are large (80MB) and are used to generate the "nnmc.cal" files. I don't know what nnmc stands for, but these files are smaller (4MB or something like that) and actually get put on the dog). You can always derive a nnmc.cal file from a *.kernel file, you can't edit an nnmc.cal file directly (well, we don't have tools for it, all it is is a lookup table mappiny YUV to symbolic colour). To make a calibration, click on "New", then whenever you click in the image you will classify that YUV colour as the symbolic colour you have selected. Once you are done, click on "Save nnmc.cal" and it will make the smaller file and put it in the offvision directory. Copy this file to the robot/cfg directory and then when you run ins, it will be put on the stick and used by the robot. There are a couple of different visualisations in Offvision. On the left you can choose between YUV, C-Plane and None. Note that if you choose C-Plane, then it will show the C-Plane generated by the nnmc.cal file that was loaded when offvision started, which probably isn't what you want for this (but it is useful for comparing stuff). When you click on the "Live" button, it will use the C-plane generated from the kernel that you are currently editing. In the colour calibration tab there are some "overlays" you can add which will show things too... just play with them, they should all make sense. They are all dealing with the C-plane from the kernel you are editing. Finally, a lot of the tools are hacked together (you've probably worked that out already). Especially for wireless stuff, if it doesn't work, try doing it again. senddata is very bad for this (it uses UDP without any reliability checks, and the protocol means that a dropped packet can change things in unexpected ways). I also am forgetting a bit of the stuff, so I might have got some details wrong. I only used offvision and worldviewer, so I can help you with them. With compiling problems, I think gcc 4 broke some stuff, so 3.4 seems to be a bit better. Let me know if you need any more assistance. Andy ----------- from Alex North to Andy Owen cc paulenepurdy@gmail.com date Feb 20, 2007 3:39 AM subject Re: Fwd: rUNSWift Robot Soccer mailed-by cse.unsw.edu.au On 20/02/2007 7:32 PM, Andy Owen wrote: >>> What I really need is a quick README for the base directory that defines >>> what each of the directories in base is. I also need some step-by-step >>> instructions for producing this color table like "Run this program by >>> typing this command, click on these things, run this program by typing >>> this command,..." etc. This will allow me to run the programs in the >>> correct order and tell me what I'm trying to do. I don't expect a huge >>> document, just a README that allows new programmers for the project to >>> get going. Could you do this for me? Or is there someone who could? > > You need 3 programs. offvision, robolink and senddata. > offvision is written in C++, and can be compiled with qmake then make. > robolink is C I think, and probably has a make file. > senddata I can't remember, but it probably has a make file too. Ah, senddata, that's it. That sends the remote control commands so that you don't need SimpleRoboCommander (or client?). I think the 2006 team make offvision work (Andy: we're talking the 2005 code release), since I never used it. Check it out, but I think subvision is what you want. -------- from Paulene Purdy to Alex North , Andy Owen , Andrew Million cc "Dr. J" , "Dr. Renner" , Ryan Mitchell , Shaun McCluskey date Feb 20, 2007 4:50 PM subject Re: Fwd: rUNSWift Robot Soccer mailed-by gmail.com OK, combining the emails I received, I did the following: base/robolink 192.168.1.114 bin/sendData 114 3 (3 is for RLINK_YUVPLANE, do I need anything else? Like 6 for RLINK_SUBVISION or something?) base/subvision/SubVision (Then I did File->Connect localhost,9000) After these commands SubVision started receiving data. From there I don't know what I'm supposed to do. The GUI is full of things I don't understand. I did, however, notice that I can load the .rlog file produced by a previous run of robolink & sendData. NOTE: 1) As Alex seemed to be implying, I don't think offvision in the 2005 codebase seems to work. I can't compile it due to some missing files. 2) There is no pPhotoTaker.py file in the codebase. So, I found base/colour/rlog2bfl. I ran it over the .rlog file produced by robolink and it produced *.BFL files. When I opened the directory full of *.BFL files from rc, I see photos. YAY! I must have done something right. I need to look at rc further to see if I have any questions about it. Thanks, Paulene ---------- from Alex North to Paulene Purdy cc Andy Owen , Andrew Million , "Dr. J" , "Dr. Renner" , Ryan Mitchell , Shaun McCluskey date Feb 21, 2007 2:39 PM subject Re: Fwd: rUNSWift Robot Soccer mailed-by cse.unsw.edu.au On 21/02/2007 11:50 AM, Paulene Purdy wrote: > OK, combining the emails I received, I did the following: > > base/robolink 192.168.1.114 > bin/sendData 114 3 (3 is for RLINK_YUVPLANE, do I need anything else? That's all you need for the images. Other streams are for other raw or semi-processed data. > Like 6 for RLINK_SUBVISION or something?) That's a stream of symbolic image features. Subvision can recognise it (but there won't be much until the colour calibration gets close). RLINK_SUBOBJECT is recognised objects. > base/subvision/SubVision (Then I did File->Connect localhost,9000) > > After these commands SubVision started receiving data. From there I > don't know what I'm supposed to do. The GUI is full of things I don't > understand. I did, however, notice that I can load the .rlog file > produced by a previous run of robolink & sendData. Yes, logging images is probably best, so you can replay them and analyse them. Most of the controls in subvision are most useful when replaying a YUV log file, where it runs the robot vision code locally and processes the images. You can load your generated nnmc.cal into it to see how good it is. > NOTE: > 1) As Alex seemed to be implying, I don't think offvision in the 2005 > codebase seems to work. I can't compile it due to some missing files. > 2) There is no pPhotoTaker.py file in the codebase. Hmm, strange. You can use senddata, or perhaps later write a pPhotoTaker behaviour - it simply has to call a method in VisionLink.py, something like sendYUV(). > So, I found base/colour/rlog2bfl. I ran it over the .rlog file produced > by robolink and it produced *.BFL files. When I opened the directory > full of *.BFL files from rc, I see photos. YAY! I must have done > something right. I need to look at rc further to see if I have any > questions about it. Great, that's all the right stuff to do. Good luck.