Category Archives: Feldman Project

Thomas DeVito

Start: 12:00

  • I either forgot to set my alarm or did 3 math problems in my sleep.  I guess I should up the difficulty on the math problems required to turn off my alarm.
  • Wrote out a summary of how the software is supposed to work to help declutter my approach to getting it working.
  • While writing this I have decided that starting tomorrow, I will write out my goals for the day on the blog, before I start working.  Too often do I jump between things and end up confusing myself.  A checklist of goals should help a lot.
  • Worked on the default simulation.  This is the same simulation I have been using but now it has to run on the PC side and send the collision data back to the arduino.
  • Decided to make collision an independent struct so that magnitude and type can be bundled together.  Made changes to accommodate for this in the simulation, sound controller, and main data dictionary stuff.

End: 6:00

Tom Devito 12.20.2011

Start: 10:00

  • Added a temporary simulation class to act as a placeholder til we have a real one.  This could also be used to process the inputs and outputs for the animation.
  • Trying to figure out the best way to manipulate the data.  Currently what I have is a call to recieveData, which imports the data from the buffer into the appropriate data dictionary entries.  Then I run the simulation so that the data gets updated as needed, it also grabs user inputs.  After that it sends the data to the arduino.  I am starting to think that maybe I should seperate the status struct into two parts so that the arduino sensor data doesn’t get overwritten when the pc sends data.
  • Made sensorData independent from the state struct so it didn’t get overwritten when the comes back from the pc with changes.
  • Took name out of the state.  If I need the name for the output, I can get it from the dd entry name.
  • Fixed collision processing in the SoundController class.  The collision processor accepts integers between 0-900.  These values can be negative because it takes the absolute value of the collision data.
  • Decided to make a simulation base class which all simulations will inherit from, instead of the placeholder I started.  Some common variables all simulations will share is max position, scaling factor, deadzone,  sensorData input, output collisions.

End: 6:00

Tom DeVito 12.19.2011

Start: 10:00

  • I was sick on Friday so I am continuing the work started on thursday.
  • Added methods for getting the state and command struct pointers
  • Added a data dictionary entry for each fingers state and command struct
  • Making changes to the pc side to accommodate the new structs.

end: 6:00

Tom De Vito 12.15.2011

Start 12:00

  • Still working on changing over to using the sound controllers as well as switching from test data for the interface to actual data.
  • Wrote out the flow to help torubleshoot
  • fixed commands on PC side to reflect changes on the arduino side.

end 6:00

Tom DeVito 12.14.2010

Start:  10:00

  • Dong told me that one of the fingers was making a lot of noise when he came in and was getting hot.  When I powered it back up, it doesn’t seem to have any problems.  I’ll make sure teh power is off when I leave from now on
  • Made some changes to the PC side to work with the new SoundController state struct
  • Need to finish troubleshooting.  I am pretty close to having everything working.

End: 6:00

Tom DeVito 12.12.2011

Start: 10:00

  • Working on fixing my SoundController class.  I wasn’t using this for some reason but it allows each finger module to be self contained.  Removed the audio splitting stuff that isn’t necessary with individual midi controllers for each finger module.
  • Increased the com buffer to 1024 from 256 so that each finger can have its own commands each cycle.  I don’t think the will cause any slow downs but if it does I will reduce it.
  • Changed commands from being single char codes to 10 char string.
  • Changed the default baud rate to 57600 from 9600 in the pc ComUtil.  This may be the source of some of the inconsistencies that I have noticed in the past because the arduino has been running at this rate since I started using the midi controllers.
  • Added a struct called state to the soundcontroller.  This struct can be manipulated directly for volume, instrument, note changes.  Sensor data is also contained in this struct.  Commands are mostly going to be used for active changes, like switching to diagnostic and midi sequence mode.  Midi sequence mode will allow for multiple note sequences(This probably won’t be implemented for a while, for now single note mode is what will be used).  When midi sequences are implemented, commands will also determine which sequence to use.
  • Changed initialization for main sketch to work with the SoundController.

End: 6:00

Tom DeVito 12.02.2011

Start: 9:30

  • Added a few utility functions to the arduino sketch to make things a bit easier to use as well as clean up the main loop so its easier to see the flow.  The arduino side seems to be working properly now.
  • Fixed a problem where the pc wasn’t importing the received data properly.
  • The interface is still not updating right.

End: 6:00

Thomas DeVito 12.01.11

start: 9:40

  • Finished fixing up the arduino side to nto depend as much on the data dictionary
  • Finished the command class which handles commands
  • In the process of fixing the PC side.  The data seems to be passing ok but still not displaying.  Its not getting lost on the arduino side anymore though

end: 6:00

Tom DeVito 11.30.2011

Start:  10:45

  • Reorganizing everything in the arduino sketch to work with so that if it does need anything from the data dictionary it can be passed from the main.
  • The loadBuffer parameter is now just the char* instead of the name of a dataelement.
  • The checkCommand method now accepts the command struct as a parameter instead of a dataelement.
  • Added checks in the CommandHandler class to check that a command is unique before execution.
  • This really does seem like a better idea.  It keeps it more modular and the arduino side is simple enough that the datadictionary was adding unnecessary complexity.  It is still used in the main sketch to handle remote data which passes between the pc and the aruduino which is the main reason it exists in the first place.

End: 5:45