Difference between revisions of "User:Aegdss\Learning Curve"

Latest revision as of 09:18, 1 October 2008

Diary of getting up to speed

Unboxing

--aegdss 09:24:28, 2008-08-08 (CDT)

Got the camera including a few cat-5 and rs-232 Dsub shell etc which was very nice.

Dont have a POE switch and didnt want to cannibalize a cable or open the housing yet, so I bought a POE injector (POI-2000 from CP Technology via amazon).

Camera came right up, could connect via telnet and browser, could acquire images and modify settings. UI seemed a bit flakey at times (using Firefox) but that could certainly have been op error.

Changed IP to 192.168.1.9, so it would work on my lan.

Attempted to get VLC and mplayer to work, but didnt have too much luck. Streamer seemed to start as evidenced by ps and indicator on web ui. But I couldn't get client apps to receive a stream. I did manage to get mplayer to start crashing so It must have been doing something :)

Gonna try streaming with linux client and then once that is all working go back to vista.

VLC should work at least up to HD resolution on any OS. (take the last stable version of VLC. VLC need to be compiled with a liblivemedia >= 2007.02.20) We officially support only patched MPlayer. (Here also, last stable MPlayer, liblivemedia >= 2007.02.20) The patch to apply is just in mplayer-1.0~rc2/libmpdemux/demux_rtp.cpp replace #define MAX_RTP_FRAME_SIZE 50000 by #define MAX_RTP_FRAME_SIZE 5000000.

--Alexandre.Poltorak 02:51, 9 August 2008 (CDT)

Streaming

Yes, VLC seems to work when using HD or less resolution. VLC is a touch on the flaky side, It would crash when using a built in image capture device (not elphel camera). Also, I could only get vlc to work using unicast streaming (rtsp://192.168.0.9:554). But that could easily have been operator error. I'll look into that further later, but first want to test out a patched mplayer under windows. But once I set the frame rate correctly and used unicast I didn't have any problems.

VLC had bad latency, on the order of 2-3 seconds, which seemed independent of resolution. The web interface, used at the same time as the streamer, did NOT exhibit the same latency. PC CPU load was only 25% or so. The other SCINI team members reported "very low" latency using VLC under linux, so evidence points to an issue with vlc on windows.

Aside: The AJAX interface works well and is nice if a bit intimidating for the neophyte user, the tooltips help a lot. I'm curious what is the frame rate limiting factor here, I need to take a peek at the code when I get a sec.

--aegdss 14:01:39, 2008-08-11 (UTC)

Use the src...

Seems like the ajax ui eventually turns off the compressor if streaming is not on, I didnt look at the code yet though.

Please use camvc2.html and not camvc (index.html), camvc2 treat the compressor and the streamer independently. You can also do all the setup using only PHP: PHP Examples, see camera_demo.php --Alexandre.Poltorak 15:42, 21 August 2008 (CDT)

Managed to get pretty good performance using the fast server (port 8081). Just start the compressor with fpcf -jpeg and then read from 8081/img as fast as I could. Gonna write a small little app to do it and see how fast I can get it on windows.

Loaded src onto a ubuntu machine today using install_from_cvs script. Went pretty smooth with only a few glitches...

1) the tcpdump.org was down and ./install_elphel wants to grab libpcap from there. Just download it from somewhere else and put it in the ~/distfiles dir.

we will check it, normally it should take from the mirror automatically in this case. --Alexandre.Poltorak 15:42, 21 August 2008 (CDT)

2) apt-get install lex yacc doesn't work. Those are in flex and bison though, so apt-get install flex bison gets them. (This was corrected in the wiki docs...--aegdss 09:26:52, 2008-08-25 (CDT))

3) the manual install of the cris compiler had problems, but the binary distribution worked just fine.

Please have a look on: Elphel_Software_Kit_for_Ubuntu#For_developers: --Alexandre.Poltorak 15:42, 21 August 2008 (CDT)

Elphel_Software_Kit_for_Ubuntu#For_developers: were the docs I was following, (which are pretty good btw.) The line "sudo apt-get install cvs build-essential lex byacc bison libglib2.0-dev tcl gettext libncurses5-dev patch zlib1g-dev" was a problem cause apt-get couldnt install lex. I think maybe if lex is replaced by flex it would be fine. I didnt really investigate further.

I also first tried to install the cris compiler using the docs on the same page. This failed in the final step (sudo ./install-cris-tools.) I did not note the error and just went straight to the binary package (which worked fine.). Of course this is more an issue with the axis script (install-cris-tools) rather than the wiki doc which seems correct in this case. I just noted it in case anyone else has the same issue and doesnt have the time to debug the install script. I think the problem with the install-cris script is probably machine (or distribution) dependent and may work just fine for most everyone else. FWIW I'm installing on a fairly stock ubuntu 8.04.

Overall the user experience for setting up the dev environment using the binary package install for the cris tools and then elphel353_install_from_cvs.sh was really very nice and easy.

--aegdss 08:28:11, 2008-08-22 (CDT)

SCINI stuff

We are going to try to use a dual headed setup with one sensor fwd and one looking down. So looking into using the 10359 and what exactly is the best operational method of doing that.

--aegdss 14:28:38, 2008-08-21 (CDT)

Plunging into dual head

After getting a great amount of support from the elphel team, I managed to successfully test the 10359 board. Although only with one sensor module (the other I got from SCINI team didnt work, but they had mention that they thought that they had killed it (static, bad voltage, penguin attack?, who knows...).

I'm trying to procure another sensor board today.

But FWIW I got images easily through the 10359 using the following sequence of steps (provide by Alexandre Poltorak):

http://192.168.0.13/camera_demo.php

http://192.168.0.13/359/sensors_init.php

http://192.168.0.13/ccam.php?trig=async&mode=set

http://192.168.0.13/359/tests_for_96mhz.php

http://192.168.0.13/compressor.php?cmd=run

http://192.168.0.13/sync.php?role=self&fps=single

http://192.168.0.13:8081/img

Gonna dig through those scripts now, while awaiting another sensor board.

--aegdss 09:21:27, 2008-08-25 (CDT)

Also anyone interested in Dual Head should take a look at 10359_in_dual_sensor_setup

Feet to the fire

Nothing like dangerously close deadlines to speed up the learning process...

Current plan is to have a c#/wpf dual head camera control app that also allows for science annotation...All using http, no rtp.

Actually making good progress. Playing/reading all the php scripts. Got multi-threaded http image reader/display going on windows (C#, WPF). It seems plenty fast, and no noticeably latency: This is using a single sensor running through the 10359 in "Transparent" mode.

(image request, image read, display set source, display invalidate: ) 8-9 ms (320x240)
12-14 ms (640x480)
19 - 20 ms (1296x960) but starts to clobber the UI of the app .
45 - 50 ms (2592x1936) bit of stuttering and UI getting very unresponsive.

So very very promising...need to clean up the app, better thread handling, add dual head, add camera control, etc. etc....

--aegdss 14:55:08, 2008-09-02 (CDT)

Two heads are better...

Got some results attempting dual head. Managed to switch between sensors and get imagery from both, although there seems to be some issue with color and or syncs in the images. Looking into that now. But not bad for first time. Maybe I'm not stopping the compressor correctly, or not waiting long enough between stopping and starting. It currently takes about 3 seconds to do a switch (with messed up colors, but other than that working). This is kinda slow, so I may need to find a way to speed that up.

Using the php is pretty easy. Much nicer to have a bunch of custom scripts than to have to do everything by passing params to ccam.php. While I'd prefer a straight C interface with maybe a simple socket wrapper, I must admit that the php stuff makes it pretty easy.

--aegdss 15:37:58, 2008-09-03 (CDT)

Managed to get the "snapshot" mode working ok. Colors are messed up, but can acquire frames from both sensors. Here is the scripts used:

http://192.168.1.9/camera_demo.php

http://192.168.1.9/359/sensors_init.php

http://192.168.1.9/ccam.php?trig=async&mode=set

http://192.168.1.9/359/tests_for_96mhz.php

http://192.168.1.9/compressor.php?cmd=run

Then Repeat:

http://192.168.1.9/sync.php?role=self&fps=single

http://192.168.1.9:8081/torp/img/next/save

--aegdss 15:54:43, 2008-09-03 (CDT)

Doh!!!

Important tip! When comparing images from a dual headed camera, make sure the iris's on both lenses are open!!!!

Still don't fully understand phase setting, what is hitting sensor registers, etc. I do fully understand the php interface and other various ajaxy scripts etc.

Weekend reading assignment is all src code. Hope to have SW done by end of next week, at least in some usable state, which I think is doable now.

SCINI is using 3" or 4" ribbon cables, will be getting some next week.

--aegdss 16:51:49, 2008-09-05 (CDT)

All The Pretty Colors

Ok, the color issue has been resolved. Oleg and Alexandre had said multiple times to adjust phase to fix the colors, but I had thought that relative small values of phase adjustment should be used. I wrote an application (C#/WPF) that talks to some custom php scripts which allows one to quickly adjust the dcm phase of each sensor. (See below) Once this was done it took about 2 seconds to get good images on both sensors. Oleg also sent new x359 bits which fixes some slight problems causing 1 bad frame upon a sensor mux. I will release all the software at some point, but if anyone wants it sooner please email.

--aegdss 12:18:52, 2008-10-01 (CDT)