Kevin Cleary Release 1 Closeout Notes

From IGSTK

1. We decided to have one iteration per month. This could give us 6 iterations before the one year review meeting. At least the first three of these iterations should focus on continuing to develop the base classes. There are two issues: 1) how we manage the hierarchy of classes when the base class has a state machine and 2) how this one integrates with the base machine of the derived classes. Later iterations may move more toward including functionality needed for the applications.
2. We developed a plan to move forward with tracking. We currently have a wrapping of David Gobbi’s code that can be used a baseline for comparison. Sohan will have primary responsibility for continuing to develop the IGSTK tracker class and should keep Hee-su inform so Hee-su can take this over. Sohan will also do a survey of trackers and the characteristics and will present next Thursday. It would also be interesting to get a Logitech 3D mouse (check with David Gobbi as to what he has) for testing.
3. For next Thursday’s tcon, let us make it at 2 pm if possible. We need to discuss the integration / hierachy between state machine, tracker, and communication classes so Sohan can move forward. For the week after, we need to move the tcon to Wednesday if people are available as Sohan and I are away at our retreat.
4. Logging will be the responsibility of Hee-su. We need to put him in touch with Dan Blezek and Jim Miller at GE to help since they may want to put it in ITK. For logging, we discussed three possibilities of logger classes: one that is very fast for critical errors (high priority log), one that is very safe (separate thread), and the normal one. We need a separate thread so that no matter what happens to the application the critical data is saved.
5. There was some discussion on threading. We would like to support multithreading but in a control and limited way. We drew an architecture that included threads for tracking and logging.
6. For tracking, at the tracker class level we will continuously poll the tracker and keep this data in a circular buffer. The size of the buffer can be changed. The scene will have a pulse generator and will prorogate the calls through the object representation classes, to the spatial objects, to the tracker tools. The data will be “pulled�? up to the tracker tools.
7. Error handling was discussed. The idea was to propagate up event levels and let the approporatei level handle it. State machine will not have failure states, but if it receives an invalid, it will go to a valid state (could be the same) and it will report an error event as well as log the error (details TBD). There could be priorities of errors. There was some discussion and some seemed very skeptical (K2) so the concept has yet to be proven.
8. The book will be written using Latex. We will try to use the infrastructure you built for the software guide. Figures are in EPS. Visio can be used. The great advantage is that everything can be in CVS. ! Licensing objects with spatial objects viewer. If we cannot use Julien’s library directly, we need to write the ones that we need. The guiding principle is that the entire toolkit should have a single license and must be available for commercial applications (remember this a small business grant intended to develop a commercial market).