Xbow IMU400CC

Lorenzo Pollini lorenzopo at dsea.unipi.it
Tue Jan 10 09:49:02 CET 2006


> Hello Lorenzo,
>
> thanks for the tips...
>
> Actually I was wondering about
> making a RT driver that uses the support of
> the existing rtai serial port driver,
> collect data from the SP, write in a Shared memory
> and than generate an Interrupt to signalize
> data is available for anyone interested on
> reading it...


if you do not want to poll the IMU
do not forget to accurately time stamp each data packet
and try to take into account the delay
between raw sensor sampling and reception
of data packet otherwise your navigation will not work

as far as I remember the IMU400CC free run mode
does not guarantee any specific sampling frequency

With polled mode instead you can reasonably state that sampling
happens as soon as the IMU receives the command

> The same strategy for commands...someone write in the shm
> and then generate an interrupt to advise the driver a command
> was issued.
> However I'm still no certain if I should put my Navigation
> computations also in a kernel module in order to improve
> performance...or put it as a standard user space app.

with the newest RTAI versions you do not need
a kernel module to do this, a user-space process
will allow you to access HW and do FPU computations.

    Lorenzo


>
> Regards,
>
> Msc. Eng. Gustavo Baldo Carvalho
> ZARM - Uni-Bremen - Room 1210
> Am Fallturm, 28359 Bremen
> Tel:(0049)-(0)421-218-4796
> Fax:(0049)-(0)421-218-2521
>
> Lorenzo Pollini wrote:
> >>Does anyone worked already with the XBow IMU400CC in RTAI?
> >>I must devellop a driver for it to work through serial port under
> >>RTAI...any help?
> >
> >
> > You should not need a driver.
> > Since you may access the imu400c via serial port,
> > using the rtai serial port driver.
> > Which SW architecture might be preferable
> > for acquiring the data depends on your application:
> > - streaming mode (the IMU does not guarantee an
> > exact acquisition period... AFAIK it should run as fast as possible)
> > - polled mode
> >     - asynchronous (start of conversion and wait to read data when you
need
> > them)
> >     - periodic (start of conversion and read data periodically)
> >     if you may stand 1 sample delay, I suggest you to use polled mode
> >     in a periodic RTAI task
> >     (should work at least up to 50 Hz)
> >     send a request to the IMU and read
> >     the answer to previous request from the buffer
> >     (this is the fastest way to achieve periodical acquisition)
> >     the data packet is very simple and fixed size
> >     just read  those bytes in one read, checks header and verify
checksum to
> > be sure
> >     what you read is ok and extract the data from the byte array
> >
> >        Lorenzo
> >
> >
> > _______________________________________________
> > RTAI mailing list
> > RTAI at rtai.org
> > https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai
> >





More information about the Rtai mailing list