-
Leigh B. Stoller authored
* New robot event listener: * It is intended to be started and stopped from the experiment swapin path instead of as a global daemon. It takes the pid/eid of the experiment, and will deal with events only for those nodes that are allocated to the experiment. We have some long range plans of time sharing the robot lab, so I figured we might as get a little bit of a start on that. * Once it fires up, it subscribes to the usual assortment of events, just like the loclistener does. * It then binds a socket on which to listen for connections from the web server. * Then it loops, looking for events and for connections from the web server. Connections from the web server are for forwarding the event stream in real time to whatever applets are currently viewing the robot lab. * As each event comes in, it is parsed, entered into the DB (nodes and location_info table), and fired out (in a textual form) to all the applet listeners. The web interface just acts as pipe in this case for the data. * The event stream is also duplicated to a file in the experiment directory (the same stuff that is piped to the applet), named by the current resource record ID. I hope to use this stream to playback the motion in the applet (coupled with webcam images once I figure out how to sync them). * tbswap: Start and stop the new listener. * Robotrack: I changed the interface for how we actually communicate the event data. Much more reasonable then it was (a comma separated string of numbers!). * new database fields in the experiments table to hold the process ID of the listener and the port it is listening on. The port is not used yet, as the robot lab is still not shared. Will need to revist this later. Currently uses a fixed port number. * www/robotrack/robopipe.php3: Killed most of the old code and replace with simple socket connect to the listener.
5f67fe09