Thanks to all who contributed here, I'm learning a lot.
As to what is 'real time' -- as you can probably tell by watching the
video at the URL, the robots were dynamically stable - they had to react
within a millisecond (Read sensors; do all control; storage of data for
post-run analysis, run all the low-level joint servos (12 of them on the
4-legged machine) -- and because we did not have sensors for everything,
some had to be synthesized (e.g. if you have a position sensor, and you
take regular samples, you can approximate velocity). This requirement
means that you need low 'jitter' from when the pin goes high (it was
usually controlled by a clock) to when you can read the raw sensors -
obviously, that was done first to minimize this jitter. So to me, 'real
time' means response within some specific number of microseconds.
At one point, Greg, I built a Z8002 + Weitek floating point chip to sit
between the vax and the 4-legged robot. This indeed helped because now
the low-level control (servoing) was done by this Z8002+Weitek, and the
'planning' was done in the vax. It was about 4x faster than the vax
could servo; the joint motion was very smooth, because there was also
less jitter (it wasn't running unix).
We ended up not using it after all that effort because (1) The ability
to have 'everything' on one machine was a Big Win. and (2) Now you had
two different software stacks, which increases the overall complexity.
The biggest 'win' having it all on one machine was for data collection
and analysis: the kernel driver locked down a lot of memory, and wrote
dozens of sensors and computed values into a big circular buffer. When
the robot failed (which was 90% of the time), we push another button,
generating an NMI, which would freeze the circular buffer. Recall,
this driver was activated by simply issuing an ioctl() to activate the
driver. When the time-sharing part had control again, the data were
copied out of kernel space into user space with another ioctl(). And of
course the software to drive the graphics display was also on the vax,
so literally a few seconds after the robot crapped out, we were looking
at data from the run.
I think the lesson is: never discount the communications issues when
distributing computation. They add system complexity and often delay.
With the RPi4 NetBSD support coming along nicely, I'd expect to use
this. It might be nice to be able to 'dedicate' a core to servicing the
interrupt, leaving the other 3 to continue regular operation.
Multi-core I would hope would make things that much easer for this problem.
I'll look at gpioirq(4) and gpiopps(4) - sounds promising. I'm happy to
hear the Global Interrupt Enable is used for only short times; and yes I
bet a high IPL will work.
------------
There is another motive, which is to show how it's possible to run a
modern unix with a Real-Time process, specifically for robot control.
The other *nix OSs out there don't do Hard Real Time, the best I've seen
is a microkernel below a regular kernel (not rump). Again, this makes
things complicated.
I'll work on it and maybe it'll all 'just work'.
Thanks everybody,
Mike
On Sun, Apr 19, 2020 at 9:19 AM Sad Clouds <cryintothebluesky%gmail.com@localhost
<mailto:cryintothebluesky%gmail.com@localhost>> wrote:
On Sun, 19 Apr 2020 15:27:16 +0200
Johnny Billquist <bqt%update.uu.se@localhost <mailto:bqt%update.uu.se@localhost>> wrote:
> Essentially, a hard real time system guarantees that it never takes
> longer than some specified time for something to happen. And as far
> as I know, NetBSD cannot give such guarantees. Various combinations
> of events and situations can lock out interrupts for some time, and
> there is no guaranteed upper bound to that time.
Yes you're right, "hard real time" is more about not missing deadlines,
rather than how fast something can be executed. Also the consequences of
missing deadlines can be quite catastrophic, i.e. air bags not
activating in time during a collision.
The original poster mentioned something about controlling a robot with
a raspberry pi. If the robot is not doing anything safety critical,
then "soft real time" is probably something that NetBSD could provide.