[Rock-dev] Rock Performances on Gumstix

Alexander Duda Alexander.Duda at dfki.de
Tue Aug 14 13:46:10 CEST 2012


On 08/14/2012 01:12 PM, Chris Mueller wrote:
> On 01.08.2012 20:46, Alexander Duda wrote:
>> The current ruby implementation uses directly the remote task for all operations like each_port, each_property etc which are heavily used by the TaskInspector. If the network connection is bad you cannot use the TaskInspector so far. I am currently working on a ruby binding for a TaskContextProxy which will solve the freezing problem.
>>
>>> And i always receive
>>> warnings continously of:
>>>
>>> Vizkit[WARN]: ReaderWriterProxy for port payloaditem_3_cam_emi.state:
>>> ignoring method read because port is not reachable.
>>> Vizkit[WARN]: ReaderWriterProxy for portPerformance issues /
>>> TaskInspector / Port not reachable payloaditem_3_cam_emi.frame: ignoring
>>> method read because port is not reachable.
>>> Vizkit[WARN]: ReaderWriterProxy for port Performance issues /
>>> TaskInspector / Port not reachablepayloaditem_3_cam_emi.frame_raw:
>>> ignoring method read because port is not reachable.
>> You are running into a connection timeout which is set to around 2 sec for rock-display.
>>
>>> Network latency seems to be okay on the first naive view.
>> There are a number of calls to read the hole interface therefore 22ms can be quite hight.
>> I guess you need more than 30 calls to get the hole camera interface.
>>
>>> Unfortanetely, i can not test rock-display on that system itself,
>>> because we didn't install vizkit there for reducing compilation time.
>> start the camera and write a small script which is just connecting to the remote task and displaying the camera frame. This is the best you will get with your current setup.
>>
>> camera = Orocos::TaskContext.get "camera"
>> Vizkit.display camera.frame
>>
>> If you need more help, let me know.
> I have tested this now on one of our camera payload items and it simple
> returns a black/grey window with "no signal".
This means no data can be transferred from the camera to your computer. 
Have you checked that the camera is sending images?
(try to print some fields of the frame struct on the gum stick console)


>
> I have experimented with the configuration from the usb camera and
> reduced it to a 160x120 resolution. The performance via top was very low
> afterwards (oscillate between 20 and 30 percent in cpu, 40 percent
> memory consumption), but i get the same problems.
>
> I guess the network latency is therefore the reason for this issue,
> especially if need more than 30 calls for the camera interface.
The TaskInspector is not working if you have a high latency on the 
network. But there is another version on the branch proxy
which can deal with that.
>
> Is it possible to increase the timeouts manually per script?
Orocos::CORBA.call_timeout = ms
Orocos::CORBA.connect_timeout = ms

Alex

-- 
Dipl.-Ing. Alexander Duda
Unterwasserrobotik

DFKI Bremen
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 178-456620
Fax:   +49 (0)421 178-454150
E-Mail: alexander.duda at dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.:    DE 148646973
Steuernummer:  19/673/0060/3



More information about the Rock-dev mailing list