Chief Delphi
Page 1 of 3 1 23 >
Show 100 post(s) from this thread on one page

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   C/C++ (http://www.chiefdelphi.com/forums/forumdisplay.php?f=183)
-   -   New Camera Class (http://www.chiefdelphi.com/forums/showthread.php?t=81158)

TheDominis 26-01-2010 08:22
New Camera Class
 
1 Attachment(s)
BETA

I've heavily modified some camera code. There is slightly different functionality in smash_camera.cpp in GetJpegImageBlocking. It blocks with different functionality. It will not always succeed. You can change the functionality by copying the original method from PCVideoServer.cpp. Also, for now, you must manually set the IP to the computer to want to receive video from. You must do this in the method VideoServerHelper on line 65 in smash_video_server.cpp.

Required Code:

Code:
#include "smash_camera.h"

smash::AxisCamera& camera = smash::AxisCamera::getInstance();
camera.writeResolution(smash::k160x120);
camera.writeBrightness(0);
The Dashboard will fill a drop down box with all available IP addresses that are IPv4. This will automatically detect the data and start the server. If you want to stop the server, close the program. There is a timeout period of 250ms and the server status will be "waiting". The dashboard supports any Jpeg size. However, it seems to be slightly buggy on 320x240 and very buggy on 640x480. I'll be working on this.

I didn't try to 2Go PC, but I got 20+ FPS on 160x120.

I'll upload dashboard later.... must go!

slavik262 26-01-2010 11:34
Re: New Camera Class
 
I'm sorry if I'm not getting this, but what does this do? Does it give an increased framerate or is it just designed to let the user customize what IP they want to use to receive video data?

Does this run on a LabVIEW dashboard, or some custom implementation of your own?

TheDominis 26-01-2010 12:36
Re: New Camera Class
 
2 Attachment(s)
I didn't know that the zip limit was greater than the rar format. It failed for that reason.

The Dashboard frame rates at 160x120 were 20+ on the laptop I tested it on (not the 2Go computer). The other formats were less, but I think that was due to an error in the dashboard.

You will need 3.5 .NET Framework for this to work. Perhaps even SP1 for 3.5 .NET.

slavik262 26-01-2010 16:42
Re: New Camera Class
 
You still didn't really answer my question. Is this just a custom video dashboard? What advantages does this have over the standard code?

TheDominis 26-01-2010 17:25
Re: New Camera Class
 
Quote:
Originally Posted by slavik262 (Post 907354)
You still didn't really answer my question. Is this just a custom video dashboard? What advantages does this have over the standard code?
Opposed to the stock camera server, my server gets 20+ FPS at 160x120. Other image sizes are slightly buggy, but I'll fix that soon. Adding more features later.

slavik262 26-01-2010 17:46
Re: New Camera Class
 
Awesome! Without pouring through the code, how did you manage to do this?

TheDominis 26-01-2010 18:30
Re: New Camera Class
 
Quote:
Originally Posted by slavik262 (Post 907382)
Awesome! Without pouring through the code, how did you manage to do this?
Server

Step 1. Acquire Image
Step 2. Calculate how many packets will be required to send the image
Step 3. Send packet(s) via UDP (1032 byes), populate any outdated data
Step 4. Repeat 1 - 3

Receiver

Step 1. Acquire a 1032 byte packet
Step 2. Translate the packet into usable information (i.e Big Endian to Little Endian)
Step 3. Populate "Status" with new information
Step 4. If the image is finished, present it
Step 5. Repeat 1 - 4

This is, of course, a simplified overview.

slavik262 26-01-2010 18:36
Re: New Camera Class
 
So you segment the image into several packets and send it over UDP instead of TCP? I assume you have error-checking built in? I'll have to check it out.

TheDominis 26-01-2010 18:38
Re: New Camera Class
 
Quote:
Originally Posted by slavik262 (Post 907416)
So you segment the image into several packets and send it over UDP instead of TCP? I assume you have error-checking built in? I'll have to check it out.
I carry very little about errors. I throw them out and wait for a new image.

Tom Line 26-01-2010 20:17
Re: New Camera Class
 
I'm curious - how does this affect the total bandwidth used by a single Crio and dashboard.

In other words, have you increased 20-fold (or is it 20^2 for an image) the number of packets that are going to be sent to increase your framerate by 20 times?

For some reason I thought the communication protocalls were sancrosanct - that is I thought we weren't allowed to touch them because of bandwidth concerns. I had thought that was why they limited the dashboard to a 1 hz update, though I might be wrong: you know what they say about assuming.

TheDominis 26-01-2010 20:53
Re: New Camera Class
 
Quote:
Originally Posted by Tom Line (Post 907474)
I'm curious - how does this affect the total bandwidth used by a single Crio and dashboard.

In other words, have you increased 20-fold (or is it 20^2 for an image) the number of packets that are going to be sent to increase your framerate by 20 times?

For some reason I thought the communication protocalls were sancrosanct - that is I thought we weren't allowed to touch them because of bandwidth concerns. I had thought that was why they limited the dashboard to a 1 hz update, though I might be wrong: you know what they say about assuming.
I'm not sure either. The TCP stream tries to send an image pretty fast, but fails. Also it implicitly fragments, but I do not know how this affects socket I/O. I know that I use ~1MB/s for 640x480@30Hz with Jpegs drawn on the computer, but they are much larger than the camera's Jpegs at no compression. I'll post bandwidth usage for each image size tomorrow.

TheDominis 28-01-2010 19:39
Re: New Camera Class
 
Bandwidth Usage:

Code:
160x120: 100kbs
360x240: 400kbs (peak, average was around 300kbs)
640x480: Not Tested

The Lucas 28-01-2010 22:53
Re: New Camera Class
 
Good work. However, before you train drivers with this video feed available, you might want to ask FIRST Q&A if UDP traffic will be blocked by FMS at competition. Unfortunately, I assume it will be blocked, just like the PCVideoserver port was blocked last year. FIRST is obviously concerned about the bandwidth usage at competition. It would be nice if QoS was used so video could be sent at a lower priority but utilize all available bandwidth.

slavik262 29-01-2010 08:19
Re: New Camera Class
 
Quote:
Originally Posted by The Lucas (Post 908978)
Good work. However, before you train drivers with this video feed available, you might want to ask FIRST Q&A if UDP traffic will be blocked by FMS at competition. Unfortunately, I assume it will be blocked, just like the PCVideoserver port was blocked last year. FIRST is obviously concerned about the bandwidth usage at competition. It would be nice if QoS was used so video could be sent at a lower priority but utilize all available bandwidth.
Already being done. Yesterday we submitted a question to the Q & A forums. This system won't use any more bandwith than the WPI version (in fact it will probably use less due to the more unstructured nature of UDP and the fact that this system doesn't re-transmit packets that get dropped or lost).

TheDominis 29-01-2010 21:54
Re: New Camera Class
 
The source code can be found by using svn.

Code:
svn checkout http://frc-video-collab.googlecode.com/svn/trunk/ frc-video-collab-read-only
The C++ code will be updated tomorrow morning at around 10:30 EST.


All times are GMT -5. The time now is 14:24.
Page 1 of 3 1 23 >
Show 100 post(s) from this thread on one page

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi