[Rock-dev] [Ric-mars] Mars Simulating Sensors in Rock

[Matthias Goldhoorn]

On 16.08.2012 12:06, Jakob Schwendner wrote:
> Hi,
>
> I am currently setting up a simulation of the spaceclimber, and wanted
> to integrate some sensors (dynamixel/hokyo) into the simulation and also
> output the data on rock ports. I've done this for asguard a while ago,
> but It was a very manual and sometimes painful process. It was certainly
> not very generic. What I did was derive a task from orogen/mars_core,
> that would have all the input and output ports of the sensors and
> control inputs for the simulation. In the task, which runs an instance
> of mars, I manually connected to the asguard plugin and performed the
> forwarding of data from simulation to the ports / vice versa. This
> means, I have to replicate the interface of all the sensors and
> integrate them into a single module. Also the connection has to be done
> everytime a new robot is integrated.
>
> So here is an idea, that I had about improving the integration:
> - deriving simulated sensor tasks directly from the driver tasks. E.g.
> SimulatedHokuyo, SimulatedDynamixel a.s.o
> - Tasks would connect to a mars instance, receive/send sensor or command
> data, and forward it to the input/output ports of the task
>
> In this way, the dataflow could also stay the same for a simulated/real
> environment.
>
> My question are:
> - Whats your opinion to this solution, compared to the more monolithic
> approach we had before?
> - What is the best way to perform this connection to the mars process?
>
> cheers,
>
> Jakob
>
I thought about an similar solution,
my idea was to dynamically create input ports, the creation call will 
give the sensor id and sensor type.
With this method every sensors could be created, and also several 
instances of the same type. The mapping problem will be solved also by 
this method.
This method can be combined with your approach, means creating tasks 
with dynamic_input/output_ports for the sensors.
With this method you can simply try to get the instance of an sensor. 
Because of the now dynamicly_loaded_sensors in mars this method will be 
really generic.
If you want to know howto get an sensors, you could take a look into 
avalon's code.

This way will also cover the multiple-robot scenario.

The drawback is that the robot-knowledge is moved to the ruby-files they 
need to create the ports and mappings.
But the ruby-scripts need to know the ports in any case so i think this 
will be a good solution.

Maybe we could talk in person about this topic.

Matthias



-- 
  Dipl.-Inf. Matthias Goldhoorn
  Unterwasserrobotik

  Hauptanschrift Standort Bremen:
  DFKI GmbH
  Robotics Innovation Center
  Robert-Hooke-Straße 5
  28359 Bremen, Germany

  Phone: +49 (0)421 178 45-4193
  Fax:   +49 (0)421 178 45-4150
  E-Mail: robotik 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