FreeBSD and Robotics

[Murray Taylor]

I can only think of one other point for this...
Interrupt latency.  Depending on what you are attempting to do,
the variable nature of interrupt responses could be an issue.
I.e. if the system becomes io bound during a data capture cycle,
and something occurs that requires a response within a very narrow
window, it is possible to miss the window due to other interrupt
processes running.

For this reason, robotics systems often run on highly optimised
single process systems where there is a 'guaranteed' poll cycle
and / or a very minimal defined interrupt system with minimal
overheads.

mjt
 

> -----Original Message-----
> From: owner-freebsd-questions at freebsd.org 
> [mailto:owner-freebsd-questions at freebsd.org] On Behalf Of Modulok
> Sent: Monday, 18 June 2007 12:40 PM
> To: kzabbo at bellsouth.net
> Cc: questions at freebsd.org
> Subject: Re: FreeBSD and Robotics
> 
> It's only as good as the drivers you write to control the robot. It
> also depends on just how critical your "critical situations" refers
> to.
> 
> In situations where human life is directly dependent upon the
> integrity of the system, a modular kernel design has traditionally
> been preferred over the monolithic kernel designs found in Windows,
> Linux, BSD. That isn't to say that FreeBSD is unstable, in fact it's
> very stable. However, in a situation where people die if the system
> fails, there are some questions as to the safety of the underlying
> designs of these kernels. The reason for this is, (in general), device
> drivers operate in the kernel's memory space and therefore have the
> potential to bring down the rest of the system, should they fail,
> (again, in general). In a modular kernel design, where everything is
> run in user-space, if a single driver goes berserk it is entirely
> insulated from the rest of the system.
> 
> Then there are embedded systems, which are regarded as more stable
> because the hardware they run on is identical from one system to the
> next and never changes. Contrast this to operating systems that must
> run on a wide range of consumer hardware; there is a statistically
> higher probability of mistakes, just due to the increased size of the
> codebase. (In practice this doesn't always work out though, as I've
> used some embedded systems that were embarrassingly unstable). The
> smaller codebase of embedded systems and modular kernels is typically
> easier to audit, as there is far less code. Where human life is
> directly dependent, the code must be audited by a third party.
> 
> For pretty much any other "critical application", FreeBSD Release has
> been quite stable in my experience. Strip the kernel of everything you
> don't need, write good drivers and run it all on stable hardware and
> you should be fine in most situations. You'll probably go years
> between reboots.
> 
> Just my 2 cents.
> -Modulok-
> 
> On 6/17/07, kzabbo at bellsouth.net <kzabbo at bellsouth.net> wrote:
> > I've read some really good things about FreeBSD, especially 
> its virus
> > resistance and reliability.
> >
> > Will FreeBSD work on a robot that has to be trusted in 
> critical situations?
> >
> > Kevin
> >
> > _______________________________________________
> > freebsd-questions at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> > To unsubscribe, send any mail to 
> "freebsd-questions-unsubscribe at freebsd.org"
> >
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to 
> "freebsd-questions-unsubscribe at freebsd.org"
> 
---------------------------------------------------------------
The information transmitted in this e-mail is for the exclusive
use of the intended addressee and may contain confidential
and/or privileged material. Any review, re-transmission,
dissemination or other use of it, or the taking of any action
in reliance upon this information by persons and/or entities
other than the intended recipient is prohibited. If you
received this in error, please inform the sender and/or
addressee immediately and delete the material. 

E-mails may not be secure, may contain computer viruses and
may be corrupted in transmission. Please carefully check this
e-mail (and any attachment) accordingly. No warranties are
given and no liability is accepted for any loss or damage
caused by such matters.
---------------------------------------------------------------

### This e-mail message has been scanned for Viruses by Bytecraft ###