Re: (no subject)

On Mar 4, 2013, at 12:33 , [email protected] wrote:

> Dear Peter
> in order to control  a Comau robot 
> I need to use the  RTnet and RTAI libraries for the
> real time communication with the robot controller.
> The functioning is the following:
> 1) the external pc performs a blocking receiving on a previously opened socket
> 2) the robot controller sends a packet to the external pc
> 3) the pc receives the packet, performs proper calculations of the new command 
> references and send bck the data to the controller
> 4) goto point 1.
> 
> It is important to highlight that the timing is decided by the robot 
> controller. In particular, the controller 
> sent the data to the pc every 2ms, and the pc has to answer after 1.4ms after 
> having received the packet.
> In the case packet is lost, or the pc does not answer back in the proper time, 
> the robot controller enters in a faulty state (it has to be restarted).
> 
> 
> My idea is to implement in a Orocos component the thread which performs
> the send and receive functionalities and writes on a "Data Flow Port" the 
> received information 
> for the other components. In your opinion,  is it possible to realize this 
> kind of architecture?
> Have you better ideas?
> 
> Thanks in advance for your help
> Diego

We do something very similar, and here's how we architected it ...

We can use two different industrial controllers to control one of our robots; one version of the controller uses ethernet, the other a PCI-based mesh fabric. In both cases we structure the solution like this:

- A robot telemetry component blocks on a "socket" waiting for data. When data arrives the component does some basic processing, presents the data on ports, signals on an FD (that is part of a signal pipe), and goes back to sleep.

- The Robot coordinator component manages the actual robot state, and is the front end to the user space components. It uses an FDActivity on the other end of the signal pipe, waiting for the telemetry component to signal it. When telemetry arrives, telemetry data is further processed, state changes possibly occur, application data/requests are honored, and commands are sent. We use a signal pipe to decouple a potentially blocked telemetry component form stalling this component. We also use a timeout on the telemetry FDActivity.

- A robot commands component accepts a signal from the Robot coordinator, takes input data on ports, processes it, sends it out, and goes back to sleep. We sometimes use an FDactivity and signal pipe to decouple it from the Robot coordinator, or sometimes it's a more direct connection (it is implementation dependant).

We run this at 500 Hz, and return data to the industrial controller on the order of a couple of hundred microseconds after telemetry  arrives.

Of interest, we also have a "simulated" robot coordinator that just internally loops back data. The other two components aren't deployed in this situation. This is great for system testing when a hardware robot isn't actually needed.

HTH
S
-- 
Orocos-Dev mailing list
[email protected]
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev