Real Time Interpolation/Resampling

Hi,

I have a motion control system comprising a realtime component and a
non-realtime component. Simple 2D data (position/time) is being streamed
from the non-realtime area into a FIFO queue in the realtime area. I have a
few things that I'm hoping someone could help me with:

The realtime component needs to keep running at all cost. Thus, when data
is delayed, my buffer is in danger of running dry.

There may be several options, and I'm unsure which one is best:

1. Ensure the buffer is N elements deep before I allow the realtime
component to start popping off the queue. N is determined by
trial-and-error testing and will be the number of cycles in an assumed
maximum delay. E.g. by assuming the non-realtime component will never delay
beyond 5 cycles, I can start the realtime component when the buffer reaches
5: it will then never run dry.

2. Add a second 'backup' buffer that holds predicted data (of fixed
arbitrary size M) beyond the end of what's available in the first buffer.
The realtime component will then switch to this backup if the first buffer
runs dry; it will switch back as data becomes available. The backup buffer
needs to dynamically update every cycle, e.g. as new real data comes in.

3. An alternative method?

Is there a standard way for transferring data from non-realtime to
realtime, ensuring realtime always has something to work on?

Thanks in advance!

On Jan 20, 7:27&#4294967295;am, "FatScouser" <john.ha...@truebit.co.uk> wrote:
> Hi,
>
> I have a motion control system comprising a realtime component and a
> non-realtime component. Simple 2D data (position/time) is being streamed
> from the non-realtime area into a FIFO queue in the realtime area. I have a
> few things that I'm hoping someone could help me with:
>
> The realtime component needs to keep running at all cost. Thus, when data
> is delayed, my buffer is in danger of running dry.
>
> There may be several options, and I'm unsure which one is best:
>
> 1. Ensure the buffer is N elements deep before I allow the realtime
> component to start popping off the queue. N is determined by
> trial-and-error testing and will be the number of cycles in an assumed
> maximum delay. E.g. by assuming the non-realtime component will never delay
> beyond 5 cycles, I can start the realtime component when the buffer reaches
> 5: it will then never run dry.
>
> 2. Add a second 'backup' buffer that holds predicted data (of fixed
> arbitrary size M) beyond the end of what's available in the first buffer.
> The realtime component will then switch to this backup if the first buffer
> runs dry; it will switch back as data becomes available. The backup buffer
> needs to dynamically update every cycle, e.g. as new real data comes in.
>
> 3. An alternative method?
>
> Is there a standard way for transferring data from non-realtime to
> realtime, ensuring realtime always has something to work on?
>
> Thanks in advance!

To make sure the FIFO stays around the half-full mark, you could
consider varying the rate at which it is filled as a function of how
full it is. If it starts to get empty, fill it faster. If it starts to
get full, fill it slower. This would be a crude phase locked loop.
Search terms include "elastic store", "jitter buffer", "rate locked
loop".

John

>On Jan 20, 7:27=A0am, "FatScouser" <john.ha...@truebit.co.uk> wrote:
>> Hi,
>>
>> I have a motion control system comprising a realtime component and a
>> non-realtime component. Simple 2D data (position/time) is being
streamed
>> from the non-realtime area into a FIFO queue in the realtime area. I
have=
> a
>> few things that I'm hoping someone could help me with:
>>
>> The realtime component needs to keep running at all cost. Thus, when
data
>> is delayed, my buffer is in danger of running dry.
>>
>> There may be several options, and I'm unsure which one is best:
>>
>> 1. Ensure the buffer is N elements deep before I allow the realtime
>> component to start popping off the queue. N is determined by
>> trial-and-error testing and will be the number of cycles in an assumed
>> maximum delay. E.g. by assuming the non-realtime component will never
del=
>ay
>> beyond 5 cycles, I can start the realtime component when the buffer
reach=
>es
>> 5: it will then never run dry.
>>
>> 2. Add a second 'backup' buffer that holds predicted data (of fixed
>> arbitrary size M) beyond the end of what's available in the first
buffer.
>> The realtime component will then switch to this backup if the first
buffe=
>r
>> runs dry; it will switch back as data becomes available. The backup
buffe=
>r
>> needs to dynamically update every cycle, e.g. as new real data comes
in.
>>
>> 3. An alternative method?
>>
>> Is there a standard way for transferring data from non-realtime to
>> realtime, ensuring realtime always has something to work on?
>>
>> Thanks in advance!
>
>To make sure the FIFO stays around the half-full mark, you could
>consider varying the rate at which it is filled as a function of how
>full it is. If it starts to get empty, fill it faster. If it starts to
>get full, fill it slower. This would be a crude phase locked loop.
>Search terms include "elastic store", "jitter buffer", "rate locked
>loop".
>
>John
>

I see - thanks John.

On Wed, 20 Jan 2010 06:27:38 -0600, FatScouser wrote:

> Hi,
> 
> I have a motion control system comprising a realtime component and a
> non-realtime component. Simple 2D data (position/time) is being streamed
> from the non-realtime area into a FIFO queue in the realtime area. I
> have a few things that I'm hoping someone could help me with:
> 
> The realtime component needs to keep running at all cost. Thus, when
> data is delayed, my buffer is in danger of running dry.
> 
> There may be several options, and I'm unsure which one is best:
> 
> 1. Ensure the buffer is N elements deep before I allow the realtime
> component to start popping off the queue. N is determined by
> trial-and-error testing and will be the number of cycles in an assumed
> maximum delay. E.g. by assuming the non-realtime component will never
> delay beyond 5 cycles, I can start the realtime component when the
> buffer reaches 5: it will then never run dry.
> 
> 2. Add a second 'backup' buffer that holds predicted data (of fixed
> arbitrary size M) beyond the end of what's available in the first
> buffer. The realtime component will then switch to this backup if the
> first buffer runs dry; it will switch back as data becomes available.
> The backup buffer needs to dynamically update every cycle, e.g. as new
> real data comes in.
> 
> 3. An alternative method?
> 
> Is there a standard way for transferring data from non-realtime to
> realtime, ensuring realtime always has something to work on?
> 
> Thanks in advance!

If a part of the system has a hard deadline (i.e. "so much data in so 
much time") then it is hard real time, whether or not you're calling it 
that.

So solution 1 is out.

Only you know if 2 will work.

I have a suggestion that may do, depending on your problem.  If your 2D 
trajectories can be broken down into segments that allows the mechanism 
to stop when they are done, then you can terminate each segment with a 
delimiter that basically says "it's OK to stop here".

Then make sure that your buffer is big enough for the longest such 
segment, and never start such a segment until you've received the 
delimiter.

Or go down path '1' and just keep making the buffer deeper and deeper, 
chasing a solution that never gets fully implemented but rather just 
makes the problem less and less likely to happen but always leaves it 
latent.

-- 
www.wescottdesign.com

>On Wed, 20 Jan 2010 06:27:38 -0600, FatScouser wrote:
>
>> Hi,
>> 
>> I have a motion control system comprising a realtime component and a
>> non-realtime component. Simple 2D data (position/time) is being
streamed
>> from the non-realtime area into a FIFO queue in the realtime area. I
>> have a few things that I'm hoping someone could help me with:
>> 
>> The realtime component needs to keep running at all cost. Thus, when
>> data is delayed, my buffer is in danger of running dry.
>> 
>> There may be several options, and I'm unsure which one is best:
>> 
>> 1. Ensure the buffer is N elements deep before I allow the realtime
>> component to start popping off the queue. N is determined by
>> trial-and-error testing and will be the number of cycles in an assumed
>> maximum delay. E.g. by assuming the non-realtime component will never
>> delay beyond 5 cycles, I can start the realtime component when the
>> buffer reaches 5: it will then never run dry.
>> 
>> 2. Add a second 'backup' buffer that holds predicted data (of fixed
>> arbitrary size M) beyond the end of what's available in the first
>> buffer. The realtime component will then switch to this backup if the
>> first buffer runs dry; it will switch back as data becomes available.
>> The backup buffer needs to dynamically update every cycle, e.g. as new
>> real data comes in.
>> 
>> 3. An alternative method?
>> 
>> Is there a standard way for transferring data from non-realtime to
>> realtime, ensuring realtime always has something to work on?
>> 
>> Thanks in advance!
>
>If a part of the system has a hard deadline (i.e. "so much data in so 
>much time") then it is hard real time, whether or not you're calling it 
>that.
>
>So solution 1 is out.
>
>Only you know if 2 will work.
>
>I have a suggestion that may do, depending on your problem.  If your 2D 
>trajectories can be broken down into segments that allows the mechanism 
>to stop when they are done, then you can terminate each segment with a 
>delimiter that basically says "it's OK to stop here".
>
>Then make sure that your buffer is big enough for the longest such 
>segment, and never start such a segment until you've received the 
>delimiter.
>
>Or go down path '1' and just keep making the buffer deeper and deeper, 
>chasing a solution that never gets fully implemented but rather just 
>makes the problem less and less likely to happen but always leaves it 
>latent.
>
>-- 
>www.wescottdesign.com
>

Thanks Tim - that all sounds good. Unfortunately I can't demand the thing
to stop. I really need the crystal-ball type of extrapolator that no-one
has invented yet!

I wonder whether inserting a dynamic resampler is the way to go - that
upsamples the input as the buffer dries up, and downsamples as it fills?

FatScouser wrote:
>> On Wed, 20 Jan 2010 06:27:38 -0600, FatScouser wrote:
>>
>>> Hi,
>>>
>>> I have a motion control system comprising a realtime component and a
>>> non-realtime component. Simple 2D data (position/time) is being
> streamed
>>> from the non-realtime area into a FIFO queue in the realtime area. I
>>> have a few things that I'm hoping someone could help me with:
>>>
>>> The realtime component needs to keep running at all cost. Thus, when
>>> data is delayed, my buffer is in danger of running dry.

   ...

> Thanks Tim - that all sounds good. Unfortunately I can't demand the thing
> to stop. I really need the crystal-ball type of extrapolator that no-one
> has invented yet!
> 
> I wonder whether inserting a dynamic resampler is the way to go - that
> upsamples the input as the buffer dries up, and downsamples as it fills?

I've been puzzled since you began this thread. What kind of 
hard-real-time system can make do with outdated (anyway, stale) 
time/position data? What does the system do? Normally, position data 
tell where an object is, but with your system, it seems to be 
satisfactory to know where the object was.

Why does the data arrive irregularly? Up- and downsampling involve 
creating new samples (unless downsampling is done by an integer and 
aliasing is not an issue). You would essentially be creating plausible 
fiction.

If you run short of data and temporize, what happens next? Maybe we 
could suggest a good approach if we understood more of the system.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������