Stuff that Should Have Been Done:

  • Find the ROS Open Source code for interfacing with AVR and start looking at it.
  • Get ROS Diamondback on Gumstix by next meeting or else. Jeff/Alex Lam
  • Send Kwoo a list of spares and a populated board and tshirts. Dan S, Alex Z
  • Fix issue with the board powering up by mid-May:
    • Contains: issue with the 3.3V rail not coming up to the right voltage
  • Ben and Priya will go to Howie Choset and George Kantor for moneys
    • Alex and Ben talked to Kantor
      • Possibly sell them?
  • Contact the following companies for funding: Other Alex, Prashant, Jeff, Ben
    • DigiKey
    • Find companies and contact them
    • Sparkfun
      • You weren't paying attention :P SparkFun doesn't give out donations, that's why they have free day
  • Dshope and Alex will talk about getting money from companies
  • Prashant will research how best to send packets over network and get ideas for a rough packet structure.
    • Avr_bridge may have packet structure for interfacing over UART
    • Probably has done most of our work for us
    • Find out overhead with this structure

Addressed by D.Shope

  • Figure out how fast sonars can poll with fastest speed of scanning
    • We already knew this for months - 49ms between reads, minimum DS
    • Motor can move during last 12ms + 1ms buffer for ~20Hz refresh rate DS
  • Find out Colony 3 hardware bandwidth
    • Contact Rich Hong about this - Done
      • Update was sent in email to the Scout list (see thread, not pasted here)
      • Basically, wireless bandwith is good

Addressed by Kwoo

  • Currently have 5V and 3.3V working. The issue with the 5V rail on the board dshope sent me was that a feedback resistor was not soldered down correctly (it was soldered, but not to the board). Once that was fixed we now have a nice solid 5.048V and 3.34V rails.
  • The 1.8V Gumstix rail works. It's reporting 2.24V unloaded but once I put a small load on it with a resistor I got it to drop to 1.8V. Disconcerting is that it is totally ignoring the shutdown signal though. Not sure if it will actually matter though.
  • Currently I have bypassed the pushbutton controller in terms of the regulator enable line. The protection FET (preventing backwards battery insertion) on the battery lines seems to be working as is the FET to select battery over charging (not tested with charger plugged in though).
    • Two power contacts, charger and battery. We can remove battery and run robot from rear of robot on charging contacts. You must now always have battery present, because charging interfaces only with battery.


  • I can't test the charger without a battery btw so if you guys want me to double check that you should send me one or two that you don't mind perhaps being blown up.
    • Reimburse him for batteries through pay-pal/money
  • It might streamline the next version to only let the charger charge the battery and let the battery power the system. We do this on one of our boards at work and it works well, the only caveat being that we need to always have a battery plugged in to run the board (though that may be a consequence of the charge IC and nothing else). This could get rid of this pushbutton IC and we can either replace it with a simpler pushbutton controller or axe it all together.
    • We have two contacts for charging. We can remove one and use the charging contact for power, but that would require the battery to always be plugged in because the charger interfaces only with the battery.


  • Need a 10K pullup from EN on the push button controller to VCC
  • Remove R4

Stuff To Do: