|
[DPRG] Processing unit for mobile robot
Subject: [DPRG] Processing unit for mobile robot
From: John Swindle
swindle at compuserve.com
Date: Thu Apr 24 10:07:39 CDT 2008
Randy wrote: "Now my basic opinion is today with a program like
LabVIEW I can get to 1mS timings on the PC even under windows,
but Robert had problems, ..."
I attended the recent LabVIEW seminar in Richardson and I asked
the apps engineers what the real-time loop rate is for LabVIEW in
different situations. With one notable exception, the loop rate
depends entirely on the host and on the number of tasks that
LabVIEW has started. Basically you have to empirically figure it
out. While the timing resolution in LabVIEW can be milliseconds
or better, that does not mean a loop rate of a kilohertz.
The notable exception is the LabVIEW FPGA that can be embedded in
the backplane of industrial controllers to give microsecond
resolution and loop rates that are closer to that. Way beyond
hobbyist prices.
Here's an armchair observation: When jitter seems to be a
problem, is it possible to ask what time it is and write code
that uses the actual delta time since the last iteration, instead
of assuming what the loop rate is? Maybe the system can tolerate
a lot of jitter, so long as the loop rate is not assumed to be
constant, and instead is assumed to be bounded within a jitter
budget. (The interrupt latency to read the real-time clocks of
PCs is probably too high for this sort of thing, but the host CPU
clock counter can be read very quickly, and is useful for this
purpose unless the CPU is in a power management mode, and even
then, the CPU vendors are working on ways to provide a counter
that is impervious to (most) power states.)
John Swindle
More information about the DPRG mailing list
|
