Monthly Archives: January 2012

Blog Search Tags

Many times I find it hard to find the information I want in to blog among the other entries.  These tags will help to flag important information, to filter some of the more trivial stuff out(if you want more added to the list I will edit this post):

#NOTE:  Something interesting that was found
#IMPROVE:  Something that needs optimization
#FUTURE: Something that you want to remember to look into

#ATTENTION:  Something that you want the other people on the project to read

#LIMITATION:  For noting limiting factors such as memory constraints and what not

Tom DeVito 1.23.2012

Start: 10:30

  • Working on changes to ComUtil.  Since the basic communication should work independent of all the other stuff sent over the wire, the state and size of the potential incoming packet will be transferred in the smallest way possible.
  • Made the following changes to ComMgr:
  1. Made send and recieve as simple as possible so ComUtil does all the heavy lifting
  2. Took out all buffers at this level.  The pointer to the buffer is passed into the methods
  • Changes to ComUtil:
  1. After trying to figure out how to do this and writing and rewriting the same part, I decided to model this class after the typical controller.
  2. This class does not inherit from controller because I wanted it to be lighter weight
  3. This class also runs in Master and Slave mode.  In the case of this program the PC will always be flagged master and the Arduino will be the slave.  The master controls the uid incrementing and the slave always echos.
  4. A large buffer will be broken into smaller packets
  5. decided since the buffer was a static size, it made sense to just send the packets in a way to match that size.  Its currently send 4 packets of 128 bytes regardless of if its full or not.  I can change this later if there are speed issues.
  • Finishing up ComMgr(Arduino)
  • Designated some flags for blog entries to make finding important information easier.

#IMPROVE:  ComMgr(PC) needs a non-blocking receive

#IMPROVE:  Send and recieve expect the whole 512 buffer split into 4 128byte parts.  This can be done more efficiently if needed.

Phil 1.23.12

8:30 – 5:30 FP

  • Fixing up a few things with eyepoint control, then adding the hand
  • Got sidetracked about adding text overlay capability. Also, to truly make the eyepoint controls work, the eye vector needs to be transformed by the view matrix rotational component
  • Big lesson of the day – if you declare a static variable in the header file, you must reference it outside the methods in the .cpp file. But Dprint() is now working as an overlay!
  • Filled out paperwork for Clif’s project, looks like there is progress.

Tom DeVito 1.20.2012

Start: 9:00

  • AVR studio is not really made for the arduino.  Supposedly you can drop the compiled .elf file into the debugger but I haven’t found where this is.
  • Fixed the problem where the arduino was not responding to the first packet the PC sent
  • Fixed the problems that were causing the data dictionary to crash on send and import if no data was there.
  • While doing the above I found where the .elf file is:  C:UsersThomasAppDataLocalVMicroArduinoBuildsDataCommunicationTestmega2560
  • User name and project name are case dependent of course.
  • Still not exactly sure what to do with the file.  Most forums I read just say drop it in the debugger….
  • Added a base class for the arduino sides communication.  This is so ComUtil can be the same on both sides despite having completely different base methods.  On the PC ComMgr serves this purpose.
  • Changing ComUtil to have states and send messages to ensure sychronization.  Once this is done I’ll try to figure out where the debugger thing is.

End: 5:00

Phil 1.20.12

8:30 – 5:30 FP

  • Since I have to change my insanely long FGM password, I swing by the customer to check all my passwords. They won’t need changing for a while. Looks like FGM’s password schedule is now at a different frequency. More stuff to remember. I think it’s crowding out the calculus.
  • Working on the Fl_GL_Window extension (Gl_View_Window) that will handle the drawing of all the items in the universe. Got the callback working nicely.
    • Add mouse functions for world and camera control – mostly done.
  • Working out how to set up callbacks using Fluid. Remarkably, it seems to be making sense.

Phil 1.19.12

8:30 – 4:30 FP

  • Gave Dong my copy of the OpenGl Superbible so he can have a good grounding
  • Set up a window in Fluid that has all the pieces needed for display and testing
  • Figure out timers in C++ (FLTK?) and incorporate. Working, though I can’t get a callback to work inside of a class. I may need to go to FLTK 3.0? Downloading and testing. Nope, doesnt work.
  • The way you do callbacks with classes is to have the callback be static. You pass the “this” address of the class in so that you can work with the class that is active at the moment. This is covered in detail here:, which is from the generally useful

Tom DeVito 01.18.2011

Start: 10:00

  • Trying to get AVR-Studio to work
  • In order to use it with c++ you have to install an extension from tools -> extention manager
  • Finally included all the dependent files, I can actually start debugging now.  There might be a better way to point it at the directory but for now I just dropped them all in.  The files were in arduino_roothardwarecoresarduino
  •  Apparently you can drop a built .elf file into the the debugger from the arduino.  I haven’t figured out where this file is located yet though.  Its supposedly in the temporary folder the arduino uses before deploying to the chip.

End: 6:00

Phil 1.18.12

8:30 – 4:30 FP

    • Asked Dong to look at setting up the first pass of the chart applet using the code as a possible foundation, since it seems to be the best example of working text overlays.
    • Getting openGL running in FLTK, then porting the hand
    • Got the CubeView program compiling and linking. To do this, I pointed the “additional include directories” to point to C:/FLTK/branch1.3, which has FL/ underneath it. Then I pointed the “additional libraries directories” to C:/FLTK/branch1.3/lib. The last thing I had to do was point at the proper libraries (note that these are debug directories):
      • glu32.lib
      • fltkgl.lib
      • fltkd.lib
      • wsock32.lib
      • comctl32.lib
      • opengl32.lib
    • Once I got the system running, there were piles of “PDB” warning messages (i.e. “‘C:WindowsSysWOW64ntdll.dll’, Cannot find or open the PDB file “). You can fix these by getting the debug symbol tables from microsoft:
      •  tools->options…
        • Choose Debugging->Symbols from the list, then check “Microsoft Symbol Servers” then click OK and rebuild. Here’s a screenshot
    • Having an odd problem with setting the background color. I need to set the glClearColor() in the predraw, before every frame, otherwise it comes up as black. Not sure why.
      • Turns out that in FLTK GL windows, the graphics context is reset after things like a resize. THis means that the init code can’t be in the constructor, but rather needs to be in the draw function in the following way:
			glEnv->init(w(), h()); 	// called when the context
						// has been (re)created
		glEnv->predraw(w(), h());

Tom DeVito 01.17.2012

Start: 9:30

  • I don’t think there could be anything wrong with ComMgr but I am going to retest it to make sure.  ComMgr is the class that sets up the port on the PC side and has the most basic methods for sending and receiving data.  These seem to be working but it can’ t hurt to be sure.  This should not be confused with ComUtil which is the more specialized class.
  • I now know for a fact that the packet is built and sent properly from the PC.  The arduino doesn’t seem to be recieving properly.  I think the buffer might be getting overflowed even though I am only sending 128 bytes.
  • Might have found a better way.  Firmata is a firmware for the arduino which allows the computer to communicate to the arduino directly.  If this works it would mean that all of our software can be on the PC side which would make debugging much easier.
  • How to set it up:
  • The cpp message host doesn’t seem to be available.  It would be pretty easy to make one but I would still need the communication to work between the PC and arduino to do this.  The firmata message protocols are straight forward so it might be worth doing at some point.
  • I found this shortly before leaving today:
  • Its is a IDE for AVR chips.  From what I read it has a good debugger.  I probably didn’t find it before because I was looking for something specific to the Arduino.

End: 5:30

Phil 1.17.12

8:00 – 5:00FP

  • Continuing on with collision detection
  • But first, I need to be able to see a text overlay. Looks like lwjgl has this with their Slick-Util lib. Ugh. This is getting harder than I was hoping….
  • Moving hand code over to MSVC, after installing updates
    • Building the debug and release dlls
  • Another take on 3D. This works in your iPhone: An example of a website that uses this is And there’s, also. It’s a JavaScript library that renders to WebGL or SVG
  • Getting Started with Three.js

Tom DeVito 01.16.2012

Start: 8:30

  • Changed the DataDictionary to send one item at a time over the wire when it sends them.
  • Made a test environment for the ComUtil class independent of the datadictionary.
  • Solved a lot of issues with variables not being initialized but there still is problems
  • The arduino is not waking up after the first packet is sent to it.  I see the led light up indicating the packet was received but it doesn’t start sending data.
  • I am not going to commit these classes because I might want to reset them back to the way they were.  They worked somewhat before.
  • I was not feeling well today.  Maybe I am missing something obvious.  Hopefully tomorrow I will feel better.

End: 4:30

Phil 1.16.11

8:00 – 3:30 FP

  • Working on getting the fingertip positions out of the modelview matrix
    • mat[12] = x
    • mat[13] = y
    • mat[14] = z
  • Added the ability to change colors in the hand and joints for Dong’s test. It didn’t work on his machine at home?
  • There is something odd about how the model view matrix is being affected by the fingers? Nope – just had the test transformations happening while the view transforms were still on the stack. So local to global coordinate transformations are working. That was *much* easier than I expected.
  • Building collision detection into sphere and box. Rather than reinventing the wheel, I’m going to see if I can use a library. Checking out, and the java implementation, JBullet

Tom DeVito 01.13.2011

Start: 9:00

Primary Goal:  Get the controller test to work across the wire.

  • Adding a isDirty flag is not as easy as it would seem.  The only real link between the entry and the data is the void pointer.
  • Added a new method for setting commands to the DataDictionary.  The parameters for this method are the dd entry name and the command you want to set.  Since we are using explicit command objects to set the command, we don’t need validation.  If I go back and optimize memory usage, I will have to change this.
  • I didn’t want to send an empty buffer when nothing was there, but it seems readfile requires data to be received or it waits there forever.
  • In order to keep it synchronized at the start, the arduino does not start sending data until it recieves a empty packet from the pc.  I can see the light flash showing the computer sending the packet, but it doesn’t change the state to start sending.
  • The internal serial buffer of the arduino is only 128 bytes…  Well I guess that is the solution to a ton of problems.  I am going to have to change the way things work, to send each data item individually.  Oh well, after yesterdays memory problems, I realized this would probably be the better route anyways.
  • For some reason, the project isn’t recognizing that I changed the library which holds commgr to have a buffer of 128.  Its overflowing the ComUtil and causing it to become corrupted.
  • Need to try to find a non blocking serial method for windows

End: 4:00

Arduino serial packets can only be 128bytes each.  Larger items will have to be sent in multiple packets, but it should be large enough for most.

Mike 1.13.2012