Just wanted to point out that indeed, none of the "other" Unixes do hard
real time, and neither do NetBSD.
Unix was not designed with real time in mind, much less hard real time.
It is usually good enough for soft real time, and that sounds like what
you are looking for here as well. If you just have fast enough hardware,
you usually will get responses within a very short time. But again, that
is not what defines hard real time.
If you get into a discussion with someone else, and that someone else
says Unix can't do hard real time, he is still correct, no matter how
much you fiddled around with your RPi.
Johnny
On 2020-04-20 03:58, Michael Cheponis wrote:
> 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.
>
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt%softjar.se@localhost || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol