Linux with RTAI: how would this work?

Hi,

Let's say I'm developing a control system for a UAV and I've decided to use 
Linux with RTAI in the vehicle. I have a real-time task which does the 
actual actuation of the flight surfaces and it controls the hardware 
(motors) through GPIO pins. The RT task is talking to Linux through a fifo 
(which Linux processes see as  a block device) and Linux has a device driver 
for a wireless radio data transceiver to talk to the base station.

The problem I see is that data being fed to the RT task is non-deterministic 
since the data comes from Linux. This implies that to get proper hard Real 
Time response one would have to write a RT device driver for the wireless 
data transceier as well. In other words, the use of Linux wouldn't really 
help very much. Even in a factory setting where the UI updates are being 
handled by Linux there would still need to be a RT Ethernet driver to talk 
to other factory floor devices for the same reason as illustrated above.

So is RT Linux actually a good choice?

JR 



-- 
Posted via a free Usenet account from http://www.teranews.com

Jim Relsh kirjoitti:
> Hi,
> 
> Let's say I'm developing a control system for a UAV and I've decided to use 
> Linux with RTAI in the vehicle. I have a real-time task which does the 
> actual actuation of the flight surfaces and it controls the hardware 
> (motors) through GPIO pins. The RT task is talking to Linux through a fifo 
> (which Linux processes see as  a block device) and Linux has a device driver 
> for a wireless radio data transceiver to talk to the base station.
> 
> The problem I see is that data being fed to the RT task is non-deterministic 
> since the data comes from Linux. This implies that to get proper hard Real 
> Time response one would have to write a RT device driver for the wireless 
> data transceier as well. In other words, the use of Linux wouldn't really 
> help very much. Even in a factory setting where the UI updates are being 
> handled by Linux there would still need to be a RT Ethernet driver to talk 
> to other factory floor devices for the same reason as illustrated above.
> 
> So is RT Linux actually a good choice?
> 
> JR 
> 
> 
> 
My experience with regular linux and realtime processes
  is that everything that needs hard realtime must be in the realtime 
process, and if you give control back to the kernel by eg. calling
RTC, you must have a very light normal application that does not cause
heap fragmentation, otherwise there will be defragmentation.
The defragmentation may take tens of milliseconds.

I have not used RTAI but I assume that if you have hard realtime
requirements, all critical parts must be inside the RT processes,
even the device drivers.

Mikael

"Mikael Nordman" <oh2aun.extra@stuff.gmail.com> schreef in bericht 
news:Qaa4j.259695$vZ3.14245@reader1.news.saunalahti.fi...
> Jim Relsh kirjoitti:
>> Hi,
>>
>> Let's say I'm developing a control system for a UAV and I've decided to 
>> use Linux with RTAI in the vehicle. I have a real-time task which does 
>> the actual actuation of the flight surfaces and it controls the hardware 
>> (motors) through GPIO pins. The RT task is talking to Linux through a 
>> fifo (which Linux processes see as  a block device) and Linux has a 
>> device driver for a wireless radio data transceiver to talk to the base 
>> station.
>>
>> The problem I see is that data being fed to the RT task is 
>> non-deterministic since the data comes from Linux. This implies that to 
>> get proper hard Real Time response one would have to write a RT device 
>> driver for the wireless data transceier as well. In other words, the use 
>> of Linux wouldn't really help very much. Even in a factory setting where 
>> the UI updates are being handled by Linux there would still need to be a 
>> RT Ethernet driver to talk to other factory floor devices for the same 
>> reason as illustrated above.
>>
>> So is RT Linux actually a good choice?
>>
>> JR
> My experience with regular linux and realtime processes
>  is that everything that needs hard realtime must be in the realtime 
> process, and if you give control back to the kernel by eg. calling
> RTC, you must have a very light normal application that does not cause
> heap fragmentation, otherwise there will be defragmentation.
> The defragmentation may take tens of milliseconds.
>
> I have not used RTAI but I assume that if you have hard realtime
> requirements, all critical parts must be inside the RT processes,
> even the device drivers.
>

Exactly my point! What's the use of RT Linux in that case?

I'm wondering if eCos isn't much better suited for my application than RT 
Linux since both the drivers and the kernel are hard Real Time, there would 
be no duplication of effort.




-- 
Posted via a free Usenet account from http://www.teranews.com

On Sat, 01 Dec 2007 11:44:57 +0100, Jim Relsh wrote:

> "Mikael Nordman" <oh2aun.extra@stuff.gmail.com> schreef in bericht
> news:Qaa4j.259695$vZ3.14245@reader1.news.saunalahti.fi...
>> Jim Relsh kirjoitti:
>>> Hi,
>>>
>>> Let's say I'm developing a control system for a UAV and I've decided
>>> to use Linux with RTAI in the vehicle. I have a real-time task which
>>> does the actual actuation of the flight surfaces and it controls the
>>> hardware (motors) through GPIO pins. The RT task is talking to Linux
>>> through a fifo (which Linux processes see as  a block device) and
>>> Linux has a device driver for a wireless radio data transceiver to
>>> talk to the base station.
>>>
>>> The problem I see is that data being fed to the RT task is
>>> non-deterministic since the data comes from Linux. This implies that
>>> to get proper hard Real Time response one would have to write a RT
>>> device driver for the wireless data transceier as well. In other
>>> words, the use of Linux wouldn't really help very much. Even in a
>>> factory setting where the UI updates are being handled by Linux there
>>> would still need to be a RT Ethernet driver to talk to other factory
>>> floor devices for the same reason as illustrated above.
>>>
>>> So is RT Linux actually a good choice?
>>>
>>> JR
>> My experience with regular linux and realtime processes
>>  is that everything that needs hard realtime must be in the realtime
>> process, and if you give control back to the kernel by eg. calling RTC,
>> you must have a very light normal application that does not cause heap
>> fragmentation, otherwise there will be defragmentation. The
>> defragmentation may take tens of milliseconds.
>>
>> I have not used RTAI but I assume that if you have hard realtime
>> requirements, all critical parts must be inside the RT processes, even
>> the device drivers.
>>
>>
> Exactly my point! What's the use of RT Linux in that case?
> 
> I'm wondering if eCos isn't much better suited for my application than
> RT Linux since both the drivers and the kernel are hard Real Time, there
> would be no duplication of effort.

In your case you may not need RT Linux.

RT Linux is good where you have some complicated, non-critical stuff 
going on (as a batch process where the batch commands come in through 
Linux, or Linux is managing a bunch of different profiles), plus you have 
real time stuff.

If all you're doing is receiving radio commands and controlling surfaces, 
then maybe you're right.

On Dec 1, 11:39 pm, Tim Wescott <t...@justseemywebsite.com> wrote:
> On Sat, 01 Dec 2007 11:44:57 +0100, Jim Relsh wrote:
> > "Mikael Nordman" <oh2aun.ex...@stuff.gmail.com> schreef in bericht
> >news:Qaa4j.259695$vZ3.14245@reader1.news.saunalahti.fi...
> >> Jim Relsh kirjoitti:
> >>> Hi,
>
> >>> Let's say I'm developing a control system for a UAV and I've decided
> >>> to use Linux with RTAI in the vehicle. I have a real-time task which
> >>> does the actual actuation of the flight surfaces and it controls the
> >>> hardware (motors) through GPIO pins. The RT task is talking to Linux
> >>> through a fifo (which Linux processes see as  a block device) and
> >>> Linux has a device driver for a wireless radio data transceiver to
> >>> talk to the base station.
>
> >>> The problem I see is that data being fed to the RT task is
> >>> non-deterministic since the data comes from Linux. This implies that
> >>> to get proper hard Real Time response one would have to write a RT
> >>> device driver for the wireless data transceier as well. In other
> >>> words, the use of Linux wouldn't really help very much. Even in a
> >>> factory setting where the UI updates are being handled by Linux there
> >>> would still need to be a RT Ethernet driver to talk to other factory
> >>> floor devices for the same reason as illustrated above.
>
> >>> So is RT Linux actually a good choice?
>
> >>> JR
> >> My experience with regular linux and realtime processes
> >>  is that everything that needs hard realtime must be in the realtime
> >> process, and if you give control back to the kernel by eg. calling RTC,
> >> you must have a very light normal application that does not cause heap
> >> fragmentation, otherwise there will be defragmentation. The
> >> defragmentation may take tens of milliseconds.
>
> >> I have not used RTAI but I assume that if you have hard realtime
> >> requirements, all critical parts must be inside the RT processes, even
> >> the device drivers.
>
> > Exactly my point! What's the use of RT Linux in that case?
>
> > I'm wondering if eCos isn't much better suited for my application than
> > RT Linux since both the drivers and the kernel are hard Real Time, there
> > would be no duplication of effort.
>
> In your case you may not need RT Linux.
>
> RT Linux is good where you have some complicated, non-critical stuff
> going on (as a batch process where the batch commands come in through
> Linux, or Linux is managing a bunch of different profiles), plus you have
> real time stuff.
>
> If all you're doing is receiving radio commands and controlling surfaces,
> then maybe you're right.


--snip--
> RT Linux is good where you have some complicated, non-critical stuff
> going on (as a batch process where the batch commands come in through
> Linux, or Linux is managing a bunch of different profiles), plus you have
> real time stuff.

Its good for sales terminal or device where you always know the input.
But in this case we have few motors for pan and tilt moving same time
with radio receive/send commands. So, I would prefer a non-preemptive
behavior to do the job.  Certainly, I will consider task priority very
critically to make sure my motors move to right direction as commanded
by radio receiver ;-)

> If all you're doing is receiving radio commands and controlling surfaces,
> then maybe you're right.

All RFID readers to that trick, for example talkin to access control.

ali