legacy-roboime / ssl-vision

RoboCup Small Size League Shared Vision System
http://code.google.com/p/ssl-vision/
GNU General Public License v3.0
1 stars 0 forks source link

SSL Vision 4 Cameras #1

Open YigitOksuz opened 8 years ago

YigitOksuz commented 8 years ago

Hi, this is a great work but is there any new version of ssl vision (I mean 4cam version) compatible with windows ?

jansegre commented 8 years ago

We haven't been using our own fork for a while since V4L support landed on the official version. I would appreciate if someone had any interest on merging the official repo into our fork.

Alternatively if anybody is interested in making the official repo compile on windows from scratch I can help since I did most of the work on this repo. Unfortunately I don't have an installation of Windows to directly address this myself, neither the time to setup one.

YigitOksuz commented 8 years ago

Then you are working on ubuntu now right?

jansegre commented 8 years ago

Ubuntu on the lab and on most members computers. OS X (Mac) personally, but I don't use ssl-vision on my machine.

YigitOksuz commented 8 years ago

Thanks man. But I am still wondering whether there is any one working on windows like us. The last time we attended there were 2 cameras but now there will be 4. I am a new team member so I do not have much information and I have never worked these kind of topics. We have client in windows and we are getting data from ssl vision built on another ubuntu machine. I built new ssl vision(4cam version) on that machine but now client on windows does not work. I also try to update only client of your code and I succeeded to compile original code but I could not update to 4 cam client and I don't know why. That's why I asked :)

jansegre commented 8 years ago

If you are already able to run the 4cam version on Ubuntu, then there's no need for ssl-vision on Windows. (it is a big headache, I did this when I was a new member and had too much free time, I learnt a lot, I'm not sure I would do this again)

I know what your problem is (probably), on the new 4cam version the vision protocol has changed, and also the ports in use. The "old" (I think it was still in use last year) vision port is 10002, the new server uses 10005 (legacy, I don't know why they changed from 10002) and 10006 (new protocol). The changes mostly (or entirely?) regard how the geometry of the field is described.

It is probably enough to either configure the server (ssl-vision) to publish the legacy vision protocol to the port 10002, or configure the client to listen to the new legacy port 10005.

Note: I'm not 100% sure about these numbers (10005/10006) but you can confirm them on the ssl-vision configuration panel somewhere around network or global settings.

If you're only interested on the client/graphicalClient from our repo feel free to isolate them to their own repo, it wasn't particularly hard to port it to Windows, only ssl-vision is because of the camera API.

YigitOksuz commented 8 years ago

Actually, yes protocol and some geometry information has changed. I adjust the protocol by changing protobuf to newer version(i.e. protobuf 2.2.0) and I also replaced the libraries of 2cam and 4cam repos because as you said there are geometry changes. Then, I try to make 2cam client main.ccp code to look similar to 4cam client main.cpp by comparing them like what data ssl vision sends etc. After all these, I wanted to compile but that gave error:LNK2005. Most probably something needed to be changed in libraries but I can say that you think right. Due to these geometry info changes, client runs in windows could not parse the data because it couldn't recognize the data that ssl vision sent.

YigitOksuz commented 8 years ago

By the way you said "It is probably enough to either configure the server (ssl-vision) to publish the legacy vision protocol to the port 10002, or configure the client to listen to the new legacy port 10005." Is that all ? I mean there are some changes in main.cpp of client. Even if I dont change anything(as if there are still 2cams) and by adjusting this port thing, can I get the correct data ?

jansegre commented 8 years ago

Yes, the changes to the geometry data don't need to be reflected on the graphical client (yet) because the server still sends the old geometry data (the legacy protocol, which by the way only very recently became legacy). What matters is making the graphical client (from this repo) receive the legacy packets.

The alternatives I see are:

  1. [easy] Change the graphical client's code (because I think it's hardcoded) to receive from 10005 (I'm not entirely sure about this port) instead of 10002.
  2. [easier] Configure the ssl-vision (which you said it's running on Ubuntu) to send the legacy packets to the port 10002 (because that's where the graphical client uses)
  3. [hard] Adapt the graphical client (from this rep) to use the new geometry format instead of the old one.
  4. [medium] Port the graphical client (from the official repo) to Windows

From what I understand your trying to do 3. I suggest you try 1 and 2 first.

YigitOksuz commented 8 years ago
    /* from old client main.cpp
    const SSL_GeometryFieldSize & field = geom.field();
            printf("Field Dimensions:\n");
            printf("  -line_width=%d (mm)\n",field.line_width());
            printf("  -field_length=%d (mm)\n",field.field_length()); // ok
            printf("  -field_width=%d (mm)\n",field.field_width());// ok
            printf("  -boundary_width=%d (mm)\n",field.boundary_width());// ok
            printf("  -referee_width=%d (mm)\n",field.referee_width());
            printf("  -goal_width=%d (mm)\n",field.goal_width());// ok
            printf("  -goal_depth=%d (mm)\n",field.goal_depth());// ok
            printf("  -goal_wall_width=%d (mm)\n",field.goal_wall_width());
            printf("  -center_circle_radius=%d (mm)\n",field.center_circle_radius());
            printf("  -defense_radius=%d (mm)\n",field.defense_radius());
            printf("  -defense_stretch=%d (mm)\n",field.defense_stretch());
            printf("  -free_kick_from_defense_dist=%d (mm)\n",field.free_kick_from_defense_dist());
            printf("  -penalty_spot_from_field_line_dist=%d (mm)\n",field.penalty_spot_from_field_line_dist());
            printf("  -penalty_line_from_spot_dist=%d (mm)\n",field.penalty_line_from_spot_dist());
            */

            // from new 4cam client main.cpp (not main.cpp in graphical client just client one)
    const SSL_GeometryFieldSize & field = geom.field();
            printf("Field Dimensions:\n");
            printf("  -field_length=%d (mm)\n",field.field_length()); // ok
            printf("  -field_width=%d (mm)\n",field.field_width()); // ok
            printf("  -boundary_width=%d (mm)\n",field.boundary_width()); // ok
            printf("  -goal_width=%d (mm)\n",field.goal_width()); //ok
            printf("  -goal_depth=%d (mm)\n",field.goal_depth()); //ok
            printf("  -field_lines_size=%d\n",field.field_lines_size()); //
            printf("  -field_arcs_size=%d\n",field.field_arcs_size()); //

I think these are represents geometry changes. In our windows machine, client.exe runs and when data arrive, it simply prints to the black command window. However, when I run new ssl-vision form ubuntu machine it says something like "can't parse ... goal_wall_width .. missing." I am going to try tomorrow and follow the steps that you write above.

jansegre commented 8 years ago

The parser error derives from the fact that client.exe is receiving packets in the new protocol format (which doesn't have those kind of fields anymore), not the legacy one.

The ssl-vision from your Ubuntu has two ports configured, one for the new protocol and one for the legacy protocol. Either configure the legacy port to 10002 or configure client.exe to listen on whatever is configured there (I assumed it was 10005, but I'm probably wrong since it failed.

Alternatively, if you may completely ignore geometry packets for now by commenting that piece of code.

Also, there is not much meaning to check those lines individually because the protocol format as a whole changed (new, old), so the fields that do not error will read garbage/nonsense data when trying to parse new protocol packages with old protocol code.

Jasstkn commented 7 years ago

Hi, guys. Can you help me with graphicalClient? I can't see my robots on the field and I can't understand how to solve this problem.

lucbarr commented 7 years ago

Hello! In vision, are the robots blobs being detected ? And is your vision settings configured according to your field measurements?

jansegre commented 7 years ago

I would also recommend sending an email to the official mailing list ( robocup-small@cc.gatech.edu) for more visibility an quicker responses. We will try to help, but just to be clear we're only one team.

Anyway, a common mistake is running the vision from the bin directory (I did this all the time), don't 'cd' into it, run 'bin/vision' from the main dir, this affects the XML fines which are loaded from the current dir.

For more specific guidance we'd need to know a bit more about what's going on. Are you seeing the ball? If so, is its position on the graphicalClient consistent with the real position? Is your color calibration picking too little blobs or too big? Also, you might want to check the official wiki of ssl-vision: https://github.com/RoboCup-SSL/ssl-vision/wiki

Best regards, Jan Segre

On Thu, Dec 1, 2016, 21:52 Luciano Barreira notifications@github.com wrote:

Hello! In vision, are the robots blobs are being detected ? And is your vision settings configured according to your field measurements?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/roboime/ssl-vision/issues/1#issuecomment-264332339, or mute the thread https://github.com/notifications/unsubscribe-auth/AAsjDrrRLxwnZfrJGIZj0XfYMBBAji6Tks5rD13FgaJpZM4Ilpau .