8:00 – 10:30 SR (And 8:00 – 11:00 yesterday)

• Backups
• Walked through some issues with Pat.

10:30 – 4:30 FP

• Integrating test code and event management.
• Adding sound pointers to TargetSphere.

8:00 – 11:00 SR

• Backups.
• Got the list of queries that Lenny and Chris think would be a good starting point.
• Working out hours remaining on FP. Sent off to brad

11:00 – 4:00 FP

• it looks like there are bugs in the audio code. It seems that you cannot do zero speed sessions. And the writing out of results with multiple sound files looks pretty confused. I’m not sure if extra CRs are being put in there or if some of the data isn’t being written out. Need to run some more examples. And I just can’t make it break. Odd.
• Fixing the state problem. Done.
• Fixing the saving issue. Also changing the naming of the speakers to reflect Dolby or not. Done.
• New version release built and deployed.

8:00 – 10:00 SR

• Backups
• A little unpacking. Now that I have a desk, I can have some tea!

10:00 – 4:00 FP

• Adding custom speaker number and placement as per Dr. Kuber’s request.
• Looks like dot product should do the trick: 
• Done! With only a couple of string compare issues. I also had to make the speaker index jump around the subwoofer channel until I can work out how to set the EQ.

8:00 – 11:00 SR

• Backups
• Some more back and forth with Brandon W. Not sure where that’s going.
• Showed Pat VISIBILITY. She might be able to help with a proof-of-concept ROI visualization
• Poked at Dong’s dynamic panel problem

11:00 – 4:00 FP

• Added force interaction between gripper and target sphere
• Determined how to make the ratio calculation work. If the sum of all of the magnitudes on the target is greater than zero, then the ratio equals the magnitude of the sum of the force vectors divided by the sum of each magnitude. A value of 1.0 means that there is no contact. A value of 0.0 is a perfectly opposing contact. As currently implemented, if the ratio is less than 0.5, then the position of the target sphere is set to the point that lies between the two grippers, otherwise the (summed) contact force vector is applied to the target.
• Need to add walls around the work environment so that the targets can’t get out of reach.
• Need to add the metal standoffs for the speakers. I was thinking about ordering some box tubing, but the sizes weren’t optimal. I’ll bend up some metal tonight.
• Need to start adding in the code that will support the experiments
  • Task code
  • Feedback options
    • Position and pressure only
    • Position, force feedback and pressure
    • Position, pressure and vibration
    • Position, force feedback, pressure and vibration.

8:00 – 10:00 SR

• Backups
• Desk issues
• Looks like someone might be interested in Visibility pretty much out of the blue. We’ll see

10:00 – 5:00 FP

• Wired up the speakers to the old grip interface. Amp and speakers work nicely
• Now to work on the force moving the gripper.
• I also need to get the target force vector back so that I know how to move the target. Not looking forward to implementing friction…
• Hmm. Before I commit to doing it right, I’m wondering if I can look at the summed magnitude of the force vectors vs the magnitude of the summed force vectors. If the first is high and the second is low, then it means that the ball is being squeezed. Above a certain ratio, The target could simply be at the center of the sensor points.
• Assuming that the above will work, I need to do the following to targets
  • An awareness of a “floor” that provides either a limit to motion or an upward force once penetrated
  • An awareness of the forces being applied and the sources of the forces. Since these are spheres with given radius, the information to be tracked could be as simple as the center positions of the items
  • Gravity and mass?

8:00 – 10:00 SR

• Backups
• Deployed new FA, which seems to be working well
• Met Pat.

10:00 – 5:00 FP

• Building a two-fingered gripper
• Going to add sound class to SimpleSphere so that we know what sounds are coming from what collision. Didn’t do that’ but I’m associating the sounds by index, which is good enough for now
• Need to calculate individual forces for each sphere in the Phantom and return them. Done. To keep the oscillations at a minimum, I’m passing the offsets from the origin. That way the loop uses the device position as the basis for calculations within the haptic loop.
• Here’s the result of today’s work: 

8:00 – 11:30 SR

• Backups
• Training

11:30 – 4:00 FP

• Basically spent the whole day figuring out how the 4×4 phantom matrix equates to the rendering matrix (I would have said OpenGL, but that’s not true anymore. I am using the lovely math libraries from the OpenGL SuperBible 5th Edition, which makes it kinda look like the OGL of Yore. Initially I thought I’d just use the vector components of the rotation 3×3 from the Phantom to get the orientation of the tip, but for some reason, parts of the matrix appear inverted. So instead of using them directly, I multiply the modelviewmatrix by the phantom matrix, Amazingly, this works perfectly. To make sure that this works, I rendered a sphere at the +X, +Y and +Z axis in the local coordinate frame. Everything tracks. So now I can create my gripper class and get the positions of the end effectors from the class. And since the position is in the global coordinate frame, it kind of comes along for free,
• Here’s a picture of everything working:
• 
• Tomorrow, I’ll build the gripper class and start feeding that to the Phantom. THe issue will be to sum the force vectors from all the end effectors in a reasonable way.

8:00 – 10:00 SR

• Backups
• Sent a note to the system security folks asking to clarify what I was responsible for installing on my virtual server.
• Need to do a status report for Tangie
• Got tooltips for RA/FA
• Meeting with Chris and Lenny. Mostly we discussed the issue of bad data in Cognos.

10:00 – 4:00

• Integrating Phantom
• Code is in and compiling, but there are mysterious errors:
• 
• 
• I think I need a more robust startup. Looking at more examples….
• Hmm. After looking at other examples, the HD_TIMER_ERROR  problem appears to crop up for anything more than trivially complex. Since both programs seem to run just fine by themselves, I’m going to make two separate executables that communicate using Named Shared Memory. Uglier than I wanted, but not terrible.
• Created a new project, KF_Phantom to hold the Phantom code
• Stripped out all the Phantom (OpenHaptics) references from the KF_Virtual_Hand_3 project;
• Added shared memory to KF_Phantom and tested it by creating a publisher and subscriber class within the program. It all works inside the program. Next will be to add the class to the KF_VirtualHand project (same code, I’m guessing? Not sure if MSVC is smart enough to share). Then we can see if it works there. If it does, then it’ll be time to start getting the full interaction running. And since the data transfer is essentially memcpy, I can pass communication objects around.

8:00 – 10:00 SR

• Backups
• Need to write up monthly status reports for Tangie

10:00 – 4:30 FP

• Continue integrating Phantom into testbed
• Need to bring headphones back for microphone
• Spent most of the day trying to figure out how to deal with geometry that has to be available to both the haptic and graphics subsystems. The haptics subsystem has to run fast – about 1000hz and gets its own callback-based loop from the HD haptic libraries. The graphics run as fast as they can, but they get bogged down. So the idea for the day was to structure the code so that a stable geometry patch can be downloaded from the main system to the haptics subsystem. I’m thinking that they could be really simple, maybe just a plane and a concave/convex surface. I started by creating a BaseGeometryPatch class that takes care of all the basic setup and implements a sphere patch model. Other inheriting classes simple override the patchCalc() method and everything should work just fine. I also built a really simple test main loop that runs at various rates using Sleep(). The sphere is nice and stable regardless of the main loop update rate, though the transitions as the positionis updated can be a little sudden. It may make sense to add some interpolation rather than just jumping to the next position. But it works. The next thing will be to make the sphere work as a convex shape by providing either a flag or using a negative length. Once that’s done (with a possible detour into interpolation), I’ll try adding it to the graphics code. In the meanwhile, here’s a video of a dancing Phantom for your viewing pleasure:

8:00 – 10:00 SR

• Backups
• Got the development environment including Mike’s old workspace set up on the integration machine
• Was able to run the PKI test code and get good results. Next is to attach to the server and step through the filter to see what’s going on.

10:00 – FP

• Finish getting the Phidgets code working in KF_Hand_3 – done
• Start to add sound classes – done inasmuch as sounds are loaded and played using the library I wrote. More detail will come later.
• Start to integrate Phantom. Got HelloHapticDevice2 up and running again, as well as quite a few demos