On Thursday 04 December 2008 03:52:58 Philippe Hamelin wrote:
> Hello,
> I am currently working on the design of the hardware architecture for a
> three axis robot. The first draft was based on the QNX operating system. We
> used a Sensoray 626 I/O card (analog in, analog out, encoder in, digitial
> I/O) with the driver supplied by the Sensoray. By using QNX, the problem of
> real-time aspect was considered resolved. We have chosen the Sensoray 626
> because it includes in one card all the functionality required to control a
> robot.

Interesting piece of hardware !

>
> For the second version of the architecture, we would like to use Orocos on
> a Linux/RTAI platform. I have several questions in relation to this choice:
>
> 1. I noticed that the Sensoray 626 card was partially supported by Comedi,
> so indirectly by Orocos. However, some features important to us are not
> supported, like the management of the index signal and the analog in/out.
> Therefore, this lead me to use the Linux driver provided by Sensoray. Would
> there be a major problem with this, even if the driver is not compatible
> with RTAI? Will I be forced to use Orocos in GNU-Linux mode? I do not plan
> to use interrupts, but I noticed in the code that they often use
> pthread_mutex to lock critical sections.

I only recommend the Comedi drivers if your hardware is fully supported as you
require. Most IO functions of RTT and OCL are only demonstrative and are not
sufficient for some applications. In these cases, a hardware component is
written which interfaces the device drivers and exposes them in the task
context interface.

With respect to your choice for RTAI. I believe you want to use the RT-comedi
support offered in RTAI and hope that your card can then be used in real-time.
In case that doesn't work, you could then also use Xenomai, which copes better
soft-hard switches. RTAI is known for being less stable in frequent hard/soft
transitions. Xenomai is *slowly* supporting comedi. But they count on *you* to
port a driver from Comedi to Xenomai. Examples are available.

>
> 2. Do you know if the Orocos and/or Comedi interface supports the
> management of the index signal? If this is not the case, I wonder how is it
> possible to make a precise calibration of a robot via the Comedi interface?

When it's not supported, we extend the existing classes and submit a patch.

> If the problem is simply to add this feature to the Orocos Device
> Interface, so this is not a problem for me. As against, if by default this
> is not supported by Comedi, then this would be an additionnal programming
> effort that I try to avoid.

I have no experience with this part of Comedi. My main source is the
comedilib/demos directory and the API docs to see what is available and how it
can be used. My guess is that you'll need 'instructions' (COMEDI_INSN_...) to
configure how the index pulse must be used.

>
> 3. Knowing that I need analog in/out and digital in/out as well as
> encoders, do you have other choices of hardware to recommend? Obviously, I
> would have to be able to manage the index signal from the encoder. I saw
> that the NI 660x is supported by Comedi, but it's not clear if the index
> signal is supported?

Not clear to me either, but the 660x is very well supported since comedilib
0.8. They are still working on it to get the API a bit more 'user friendly'
though. Now you need to use lots of INSN's to configure it correctly.

>
> Even if my problem is in large part on the features of Comedi, I send this
> message on the Orocos mailing list because I doubt that many of you have
> already had the same issue.

We're very interested in your progress. Keep on shooting.

Peter