[kepler-dev] ideas for kepler-roadnet projects (fwd)

[Tobin Fricke]

Date: Thu, 21 Oct 2004 17:54:43 -0400 (EDT)
From: Tobin Fricke <tobin at splorg.org>
To: Brandon J. Smith <bjsmith at sdsc.edu>

Here are a few ideas off the top of my head, varying widely in complexity:

1. Make an SVG-viewer actor for Ptolemy.

By using Batik, the Apache Project's SVG library, this should be a quick
matter of writing some wrapper code (~ a couple hours).  The annoying part
is figuring out the API of Batik.  I looked at it during the summer and it
seemed easy to get Batik to display an SVG document from a URL (which
could even point to a file on disk), but I couldn't find any API function
to simply render SVG provided in a String.  We do not want to write a
temporary file -- that would be quite a kludge.  I imagine that if you
subscribe to the Batik mailing list and ask how to display an SVG document
from a String you should quickly get what you need.  You can find out how
to structure the actor in Ptolemy by looking at one of the other actors
that pops up a GUI element & is embeddable in the 'run' window.  I suggest
the Shell actor as a model.

Having this SVG actor will allow us to use gnuplot (and other programs) in
a synchronous way.  Using the command line actor you can have gnuplot
digest some input and output the resulting plot as SVG (with one execution
of gnuplot per firing of the cmdline actor).  This can then be displayed
using the Batik actor.  This eliminates problems arising from having a
persistent instance of gnuplot.  Gnuplot has an impressive array of
visualisation functions and is completely free/open source, so this could
lead to some nice demos.  Combined with ps2svg, this will also solve the
problem of having a Postscript viewer in Ptolemy/Kepler.

2. Make a signal resampler actor -- important but complicated

This is a very high priority, I think.  The problem is that we can have
incoming signals that have different sample rates; and even if the sample
rates are the same, the sampling times might be different. (One 30 Hz
signal might be sampled on even-numbered seconds, and another 30 Hz signal
might be sampled on odd-numbered seconds, etc.  If you want to perform any
operation on the two signals -- add them, say -- then you need to resample
them so that they have the same sample rates and sample points).  There is
a very good web page describing this problem and its solution:

	http://ccrma-www.stanford.edu/~jos/resample/

Some trickiness is introduced due to real-time issues (how much delay can
you tolerate), but if you have some background in signal processing then
you should be able to attack this problem.

A good and impressive demo of this would be a ptolemy-based "beamformer"
fed with actual realtime seismic data (producing a "seismic radar" demo,
and also something that can feed into triggers further down the line).
Visualisation could be done via the Batik actor and gnuplot.  This will
generate some pretty pictures, eg:

	http://splorg.org:8080/people/tobin/projects/alaska/work/tap_html_example.html

3. Write an SQL interface to Datascope

I think this will be easier than many seem to think, so long as you don't
hope for full conformance with the current SQL standard (probably
impossible).  If you've had a course in databases and a course in
compilers (parsers, specifically) then this would be a fun and useful
project.  It's not really related to Kepler, however.

The O'Reily book on Lex & Yacc contains a parser for SQL.  Beware: it
seems buggy.  The code for this is checked into Antlope contrib CVS as
dbsql.

4. Get the Ptolemy interface to Datascope working & robust

Another high priority item.  I wrote db2ptolemy (based on Kent's db2xml)
which outputs a Datascope query as an array of Ptolemy records.  To make a
nice demo, run db2ptolemy from inetd, or get dbserver working, and make
some Kepler model that does something with data obtained from a datascope
database.  Figure out a security model.  Ditch the existing db2ptolemy and
write a new one based on an XSLT application that transforms the XML
output of db2xml into Ptolemy expressions.  This problem is highly
tractable, since just about any progress on it will be useful.

5. Make some kind of "orbtrigger" / packet handling model in Kepler

This is sort of a catch-all idea for models involving OrbPacket
processing.  I think Kent has a bunch of ideas along these lines. A
trigger (detector) looks for some coincidence of events and declares a new
event when this coincidence is seen.  For instance, you might have
threshold detectors monitoring the power seen on each of a collection of
seismic signals.  Each of these detectors declares an event when the power
exceeds some threshold.  These events feed into a higher-level detector
that looks for coincidence between individual seismic sensors within some
time interval, and declares an event when this occurs, which is sent to a
still-higher-level detector or other element.

Presently this sort of thing is done via a collection of shell scripts and
parameter files that form a glue to hold together various Antelope
programs.  One goal would be to replicate this functionality in Kepler, so
as to provide a friendly graphical interface for constructing processing
models.  My work in Alaska involved using Antelope to form a detector for
seismic arrays which would be interesting to do in Kepler:

	http://splorg.org:8080/people/tobin/projects/alaska/work/paper.html

That web page is probably greek to anyone but me.. unfortunately I never
wrote it up in more prosaic form, and the slides for my talk were
hand-written on transparancies that I washed after the talk.  Nonetheless
you might be able to extract some ideas from it.

6. Work on distributed processing

Briefly: In "stream processing," we have a collection of models, each of
which produces some named output stream of data (like SUM) from a
collection of source streams of data (like A and B).  Suppose there's a
model called MAKE_SUM that produces SUM from A and B.  If someone requests
the stream SUM, then the system would have to invoke MAKE_SUM, which would
then request streams A and B.  It's possible that this would lead to the
invokation of an entire dependence hiearchy of models to produce the
needed streams.  Portions of a stream that are produced can possibly be
cached on an ORB.

This system will require some look-up-table that says what stream
processors (models) are running on which machines; and which models
produce which streams, and how to run them.  In the alaska paper I linked
to above, this information was tracked via a Datascope table in a schema
creatively named "tobin1.0".  Antelope has functions like "resurrect" that
may be helpful here, even if only for inspiration.

Kepler could be used as the engine for this stream processing.  Orbs could
be used as the stream transport (for tokens between models), and VORB
would be super handy since it would abstract-away routing issues.  Bertram
is probably the person to talk to about stream processing.

7. Fancier Revelle integration

Right now the OrbImageViewer model displays the video feed from the
Research Vessel Revel (or any other IMG source).  It would be neat to have
this display other data from the ship too (position, temperature, etc).
This data is probably available in an Orb already.  Using Orb*Source
actors and maybe gnuplot/batik for visualization, maybe the general
mapping tools (gmt) as well, you might be able to put together a nice
visualisation of the ship's status.

8. Write a Parameter File parser in Java; incorporate it into an actor

There is some skeletal code for this in Antelope contrib CVS.  It will be
useful to have this if Jave / Kepler models are to communicate with
Antelope systems.  It is a pretty basic parsing task (lex/yacc or the Java
equivalent).

--

That's all that comes to mind right now -- hopefully you will see or find
some ideas that appeal to you.  I have to run off and work on my homework,
too.  Let me know what you choose to work on -- I have absolutely no free
time but the Ptolemy/Antelope stuff is fun enough that I'd be happy to
steal an hour here and there to work on things with you, & of course feel
completely free to ask questions.

Tobin

Rochester, NY