Transformer frames not displayed in vizkit3d

[dmronga]

Hi,

the transformer frames in vizkit3d are not displayed if I set Orocos::CORBA.name_service.ip to e.g. "localhost". Example:

If I do

require 'vizkit'

Orocos.initialize
widget = Vizkit.vizkit3d_widget
widget.show
Vizkit.exec

the frames show up properly. If I do

require 'vizkit'

Orocos::CORBA.name_service.ip = "localhost"
Orocos.initialize
widget = Vizkit.vizkit3d_widget
widget.show
Vizkit.exec

the frames cannot be seen in the display and they are neither available in the dropdown menus. The transformer seems to work properly, since the transforms are listed in rock-display. I am on the master branch of vizkit3d. Ubuntu 12.04.

Best,
Dennis

[dmronga]

Btw. the same problem occurs if the transformer is running on a different computer than the one where vizkit is running. Transformations seem to be ok and are available in rock-display, but vizkit3d does not show them.

[jakobs]

This seems to be connected to the transformer broadcaster. I've never looked into it. @jmachowinski or @D-Alex, could know.

[D-Alex]

The name resolution is probably not working in this case. You have to use a consistent name service name for all your scripts (the best is to use ip addresses).

In the example above the transformer is probably publishing the task via 127.0.0.1/task_name which cannot be resolved if you use localhost as nameservice name in another script.

[dmronga]

Thanks. It works when I use the same name service name everywhere

[goldhoorn]

Maybe if this is a problem for several users we should change the default naming servoce to 127.0.0.1?
Or identify why localhost does not get accepted by the transformer, instead of workarounding the problem?

[jakobs]

Fair point, should I reopen, or do you want to add another issue for that.

[D-Alex]

By default the nameservice name is empty. If someone is inconsistly changing it there is no code trying to fix this. And honestly I am not even sure if we should trying to do this. The most straight forward way for me would be to limit the name to ip adresses.

[goldhoorn]

first question:
why is localhost different than 127.0.0.1 ?
Do you compare the names anywhere?

A solution might be:
The task-context register on a specific nameserver, but the nameserver
responds with it pubilc ip, not localhost.
Maybe we could re-query the nameservice for it's public IP and then use
respond of the nameserver for the public registration, instead of the
user defined name-service.

Best,
Matthias

On 14.01.2015 23:01, Alexander Duda wrote:

By default the nameservice name is empty. If someone is inconsistly
changing it there is no code trying to fix this. And honestly I am not
even sure if we should trying to do this. The most straight forward
way for me would be to limit the name to ip adresses.

—
Reply to this email directly or view it on GitHub
#4 (comment).

Dipl.-Inf. Matthias Goldhoorn
Space and Underwater Robotic

Universität Bremen
FB 3 - Mathematik und Informatik
AG Robotik
Robert-Hooke-Straße 1
28359 Bremen, Germany

Zentrale: +49 421 178 45-6611

Besuchsadresse der Nebengeschäftstelle:
Robert-Hooke-Straße 5
28359 Bremen, Germany

Tel.: +49 421 178 45-4193
Empfang: +49 421 178 45-6600
Fax: +49 421 178 45-4150
E-Mail: matthias.goldhoorn@informatik.uni-bremen.de

Weitere Informationen: http://www.informatik.uni-bremen.de/robotik

[D-Alex]

Yes, the name is string based.

[doudou]

By default the nameservice name is empty. If someone is inconsistly changing it there is no code trying to fix this.

I am not sure I really understand what the exact problem is. Could you give more details ?

[D-Alex]

There is no real problem. To differentiate between multiple corba name services they get an identify from orcos.rb which is used to encode the full name of a task and picked up by the transformer to broadcast the task names. The identifier can be the IP address or the host name of the computer running the nameservice but must be the same across all scripts. Therefore, to avoid this pitfall we could convert the identifier always to an IP or add an alias name service. Now, we need someone doing it ;-)

[doudou]

As a workaround, we could put only the task's basename in the broadcaster. It would work for current applications (where having a heterogeneous system where it would fail is rare). That would do until we finally get rid of the broadcaster using orogen_metadata