Category Archives: Feldman Project

Tom DeVito 1.10.2011

BOLD = PLEASE READ

Start: 9:30

  • Working with Phil on primarily the controller class so far.
  • Phil had to step out so I am working on the DataDictionary
  • Changed all the isRemotes to isLocal to keep with the theme of the other classes
  • Added a addItem method which takes in DataElements.  Now you can either add a new entry with all parameters or add a DataElement.
  • Made the old getItem private.  This method is used internally but from what I can tell, publish or subscribe will take its place in external use.
  • Took the DataElement variables out of the struct.  This was obsolete code, the newer serialize method only takes the name and data, so the struct wasn’t really required anymore.
  • Added publish and subscribe methods.  I am not sure if I understand the purpose correctly, but I think it is to get the pointer to the entry no matter if it already exists or not.  I was also confused by why we would want two methods that do the same thing, but I guess the owner will publish, and the other classes, that want the data, will subscribe.
  • Moved sendRemoteData to private.
  • Committed changes to the 4 files involved with the DataDictionary/Element classes.
  • More changes to the Controller class were made, Phil wants me to make a test program for controller and related classes.
  • Cleaned up all compiler errors.
  • Added TempControllerTest(executive), TempSrgt(Top-level controller), TempLt(Mid-level controller), and TempPrivate(Low-level controller) classes to the project, to test everything related to the controller.  Once a local test works, I will have to ask Phil how to best handle remote data.
  • Parent class methods which are virtual, can be called using __super::nameOfMethod.
  • Eventually figured out why it kept telling me the child classes of controller were being considered abstract.  Apparently setting a method to equal zero makes it abstract.  This was actually in the wiki (= 0) but I thought it was an emoticon someone stuck in there…
  • I didn’t get much done because it took me so long to figure that out, but now that is done it shouldn’t take long to finish the local tests.
  • I will need to finish the classes for the test tomorrow and then update the arduino classes to test remote data.  Setting up the remote data test may also require changine the way stuff is sent over the wire.  How it is currently done is described below.

 

  • EXPLANATION OF HOW THINGS GO ACROSS THE WIRE CURRENTLY:  The way I have it set up, the entries are iterated through and the remote objects are added to a buffer.  This buffer  is then sent across the wire and the import method places everything in the correct place on the other side.  The way its currently set up, only name and data are transferred.  It is assumed the name, size of data, and isLocal will never change after initialization of the DataElement and will be uniform on both sides.  This process is handled by the sendRemoteData() method, which was designed to be run only by the executive at the end of a cycle.  Any suggestions on how to do this better are greatly appreciated.

End: 5:30

Tom DeVito 1.9.2011

Start: 11:30

  • Moving all the common classes over from the arduino to the pc.
  • The pc uses a different string class.  Hopefully this does not mess up the response and command objects.
  • Noticed that I was not passing the instance of the dd to comutil, on the arduino side, while changing the PC version
  • Fixed all the compiling errors on both the Arduino and PC
  • Tried launching the interface. For some reason its not drawing properly
  • Worked with Phil on the Command, response, state, and controller class.  Still working on some of the changes to these classes.

End: 6:30

Thomas DeVito 01.08.2011

Start: 2:00pm

  • Took inventory of all the classes and found out which ones needed methods added to them
  • Focused on the arduino side.   Made lots of changes to the DataDictionary, DataElement, command,  response,controller, and ComUtil.
  • Changes to the Controller class made it so Audio/Sensor element had to be rewritten.  This shouldn’t take long but I ran out of time last night.
  • I did not get a chance to do much with the PC side, but many of the classes I fixed on the arduino side are used by both.
  • Both sides need the main rewritten.  I expect to be able to do this by the end of day monday along with the revised audio/sensor controllers on both sides.

End: 12:00am

Phil 1.9.12

8:30 – 5:00 FP

  • Onward with shaders…
  • Building a torous
  • Checking out FLTK from here: https://svn.easysw.com/public/fltk/fltk/branches/branch-1.3
  • Started on getting Tom’s code to work.

Phil 1.6.12

8:30 – 430 FP

  • Just for kicks, looking for Arduino communication from Java, basically ’cause I don’t want to fry my brain switching gears to C++ if I don’t have to.
  • From http://www.arduino.cc/playground/Interfacing/Java:
    • The Arduino IDE itself is written in Java, and it can communicate to the serial port via the RXTX Java library. That library is very similar to the Java Communications API extension. Internally the IDE remembers which port and baud rate you used last time. Unfortunately that internal implementation can not be considered public API you can reliably use. So you will have to keep your own settings to remember which COM port your Arduino card is using.
    • Getting the Arduino IDE for windows: http://arduino.cc/en/Main/Software
    • Following along with the “Getting Started” instructions pointed to by the IDE. IN my case, they are installed with the software from the above step at file:///C:/Arduino%20IDE%20distros/arduino-1.0/reference/Guide_Windows.html
  • Installed Visual Studio – that took a while…
  • Working on hand modelling

Tom DeVito 01.05.2012

Objective:

  • Work out the bugs in Sound Controllers and related classes

start: 10:15

  • Fix a problem with the loadBuffer method of ComUtil causing it to mess up when more then one item was loaded.
  • Fixed a problem where commands uid were not properly incrementing.
  • Decided it would be easier to debug the sensor master first because it works the same way but is much less complex and easier to test by printing out the data.
  • Cleaned up the obsolete code on PC side

End: 6:15

Thomas De Vito 01.04.2012

Objective:

  • Testing and troubleshooting sound controllers

start: 10:15

  • Finished writing the main sketch on the arduino side.  Added a test mode sequence to test the audio master
  • Made changes to the main on the PC side to accommodate changes.

End: 6:15
The internet was going slowly today.  I spent about 30 minutes trying to resolve this problem to no avail.  If it persists through tomorrow I will have to call comcast.

Tom DeVito 01.03.2012

Objective:

  • Continue testing and troubleshooting audio classes

Start: 11:15

  • Still having IDE problems, on the arduino side, where it links to the wrong instance of a class or won’t link at all.
  • Decided to start a new program and manually copy over the classes instead of importing.  This seems to have solved the problem.
  • Took this opportunity to trim some of the obsolete classes and code.
  • Started rewriting the Main sketch to work with the new classes.

End: 6:15

Tom DeVito 01.02.2012

Objective:

  • Write sensor master class
  • Write sensor element class
  • Test sound master/element class

Start: 10:20

  • Wrote the sensor master class for the pc side
  • Wrote the sensor element class for the arduino
  • Started troubleshooting the sound master class.

End: 6:20

 

 

Tom De Vito 12.30.2011

Objectives:

  1. Finish the audio master class(PC)
  2. Finish the audio element class(Arduino)
  3. Make a test to see if they work properly

Start: 10:10

  • Fixed a problem in the IDE which made it so the wrong classes were being edited, making it so I had to overwrite the files each time I tested.
  • Made some changes and took inventory of the master and element classes to make sure they would work together.
  • Started working on a diagnostic test for the master and element class.

End: 6:10

Tom De Vito 12.29.2011

Objective:
1. Finish the AudioElement class

2. Test Data Dictionary changes

Start: 10:20

  • Added commands for the audio elements
  • Added command processing
  • Added responses(idle, executing, done)
  • Wrote a test to make sure that the Data Dictionary works with remote data.  Previously I was using a different method where this wasn’t handled by the actual dictionary.
  • The test was successful.
  • Made  a couple of changes to the Audio Master to reflect the elements they control.

End: 6:20

Tom DeVito 10.28.2011

Start: 10:10

  • Keep forgetting to write out my objectives at the beginning of the day.  Will try to remember tomorrow.
  • Made some more changes to the Data Dictionary to independently identify and send remote data.
  • Continued to work on the Audio Master.
  • Changed the sound controller class on the arduino side to AudioElement.  Working on changes to make it work with the Master.

end: 6:10

Thomas DeVito 12.27.2011

Approximately two hours were used to try to resolve our server issues.

Start: 10:20

  • Retooled the audio controller on the arduino side to work with the Audio Master on the pc side
  • Started working on the Audio Master.

End: 6:20

Tom Devito 12.23.2011

Start: 9:30

  • Talked to Phil about how to design the system
  • All processing should be done on the PC side.  The Arduino just receives commands.
  • Changed the Data Dictionary to recognize remote data elements and send them automatically
  • Grabbed the command and response class I made earlier and put them into the new project.  Add command verification and uid.

End: 6:00

Tom DeVito 12.22.2011

Start: 10:20

Goals

  • Finish the main on the arduino side with all changes accounted for
  • Finish AudioTactileExec on pc side.

Tasks Completed:

  • Fixed all the variable definitions and datadictionary entries to have entries for each fingers collision, state, and pressure.  Before everything was bundled in state
  • Added the new variables to the loadbuffer method which prepares the buffer for sending
  • Did the same stuff on the PC side
  • Fixed the main loop on each side so that they recieve data, process data/run simulations, prepare the send buffer, send the buffer, and then clear both receive and send buffers.  I had it running in a different order before which I think was causing the data to be overwritten before it was processed.

End: 6:20

I spent about 30 minutes trying to figure out an office internet problem.  This time is not charged to the project.

The slowness of the blog Dong observed, seems to have gotten worse.