Just to confirm Ernest's suggestion,
We are working with Jess in a real-time environment, and do a variation of what
Ernest suggests:
- One thread monitors an incoming asynchronous queue.
- Periodically, another thread processes this queue, performs some DSP (like the
'damping' mentioned below) resulting in data that is more digestible by the rule
engine.
- BUT instead of javabeans we just assert facts controlled from within these
pre-processing java objects (Proxy Pattern between signal processing objects and Jess
objects).
This provides a well partitioned and flexible environment that performs very good.
On our current hardware signals arrive on average about once every 100ms, and they
take about 2ms to process in this way: That gives the rule engine plenty of time to
chew...
Jack
[EMAIL PROTECTED] wrote:
> You could also do it so that the Bean had its own Thread that
> periodically polled the native properties, then sent notifications if
> any of them changed (or just called setX() on itself and let setX send
> the events.) I think I like this a little better than Chad's
> suggestion because then the Bean could easily apply "damping" to the
> polled values, and only send change events when a property changes
> more than some threshold amount.
>
> I think Chad Loder wrote:
> > Matt,
> >
> > My advice would be to use either a native JavaBean "publish"
> > model, or a periodic polling model, but I wouldn't advise
> > trying to combine both models.
> >
> > If you want to write a native JavaBean that publishes property
> > change notifications, you will need some way to get notifications
> > on the native side...your ability to do this will be governed by
> > how the native code updates the robot state. If you can modify this
> > code, you can cause notifications to be published by your bean
> > whenever a native property gets updated.
> >
> > In general, there is no way to simply "listen" to a C/C++ struct
> > for changes, in the absence of explicit signalling methods (POSIX
> > signals, Win32 events, or what have you).
> >
> > If you want to use a polling solution, this can easily be accomplished
> > with Jess (as long as you have no real-time requirements). Simply
> > use a rule with an extremely low salience and a "match any event"
> > pattern, e.g. something along these lines:
> >
> > (defrule poll-robot-state
> > (declare (salience -1024))
> > =>
> > (try
> > (bind ?state (call ?*RobotInterface* getNativeRobotState))
> > ; assert robot state facts here...then possibly do a
> > ; Thread.sleep?
> > catch
> > (call ?ERROR printStackTrace)
> > )
> > )
> >
> > Such a rule will fire pretty much continuously whenever there are
> > no other pending activations.
> >
> > Hope this helps.
> >
> > Chad Loder
> > Rapid 7, Inc.
> > http://www.rapid7.com
> >
> >
> > At Thursday 9/6/2001 04:37 PM -0400, [EMAIL PROTECTED] wrote:
> > >Hello,
> > >
> > >I am working on controlling a robot using Jess to provide the deliberation.
> > >The robot state (position, velocity, status, etc..) are available through C
> > >functions. I have made an interface that allows me to access them through
> > >Java. I am trying to determine the best way to maintain the state of the
> > >robot in a rule engine. So far, I have tried asserting each property as a
> > >fact, and then having an update function that is called at the end of each
> > >rule to retract the existing facts and assert new ones. I also tried using a
> > >template containing a slot for each property. I haven't tried using a Java
> > >Bean because I am not that familiar with them, but they seem to be the best
> > >idea. Here are a few questions I would like input on:
> > >
> > >1) Which of these formats seems best?
> > >2) Is there a way to monitor items in a C struct and keep the correlating
> > >Bean properties updated?
> > >3) If that is not possible, how can I run a continous (every few seconds at
> > >least) polling of the robot to keep my properties updated?
> > >
> > >These Properties are not being used for time critical issues (ie. obstacle
> > >avoidance), but I would like fairly frequent updates so that decisions are
> > >reasonably timely.
> > >
> > >Thanks for any suggestions,
> > >matt
> > >
> > >---------------------------------------------------------------------
> > >To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
> > >in the BODY of a message to [EMAIL PROTECTED], NOT to the
> > >list (use your own address!) List problems? Notify
> > >[EMAIL PROTECTED]
> > >---------------------------------------------------------------------
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
> > in the BODY of a message to [EMAIL PROTECTED], NOT to the
> > list (use your own address!) List problems? Notify [EMAIL PROTECTED]
> > ---------------------------------------------------------------------
> >
>
> ---------------------------------------------------------
> Ernest Friedman-Hill
> Distributed Systems Research Phone: (925) 294-2154
> Sandia National Labs FAX: (925) 294-2234
> Org. 8920, MS 9012 [EMAIL PROTECTED]
> PO Box 969 http://herzberg.ca.sandia.gov
> Livermore, CA 94550
>
> ---------------------------------------------------------------------
> To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
> in the BODY of a message to [EMAIL PROTECTED], NOT to the
> list (use your own address!) List problems? Notify [EMAIL PROTECTED]
> ---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list (use your own address!) List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
