Arduino passthru needs better error codes, as right now it doesn't really have any.

Whenever the keepon boots with its normal firmware, it rotates itself until the pins on the circuit board line up with the bottom metal plate, to center the motors. When we ground out the bus, this doesn't happen. See what the master node sends on boot to know if there's a way we can trigger this calibration.

Original comment: http://disq.us/6iwldk?imp=cce7d05a-a21a-43d8-941c-a3e31ea21eee&thread=465932670&zone=email_notification&event=shortener_click

I just got my Arduino Mega controlling the MyKeeopn, and a few notes that people might find useful:

• didn't need a 5v 3.3v converter, because I2C uses open-drain pins. Just connected both the I2C lines to the +3.3V supply from the Keepon through some pullup resistors
• needed to manually change the Arduino I2C frequency from 100khz to 25khz (which is the Keepon's I2C freq) by adding this line before beginning any Wire commands (adds a 4x prescaler to the TWBR register):
  sbi(TWSR, TWPS0);

Thanks qdot for all the info, it was really helpful!

If the keepon is powered off, we need to kick back into bootup mode so we can pull the bus pins low. Unfortunately, there's no Wire.end() call that will call twi_close() for us, meaning that twi still has its interrupts set on next keepon powerup and we can't pull the lines to stop the bus from communicating. We need to be able to stop the interrupts and go back to "normal".

Using an arduino to communicate, if a sound command is sent without a motor command being sent before it, the address portion of the message will NACK.

This may not happen with other chips, see discussion at http://www.nonpolynomial.com/2011/11/09/mykeepon-hacking/#comment-359766077

Sending 2 bytes to device 0x55 address 0x0 seems to cause keepon to sway side to side (if the first byte is < 0x80) or move up and down (if the first byte is > 0x80). Figure out exactly what these mean

Now that we can iterate through sounds (minus the issues inherent in bug #1), run through the banks and document all of the sounds.

Device 0x55 Address 0x6 is different than other Device 0x55 parts, since it only takes one byte as an argument (as seen from sniffing the bus). Running through the full range, the bot seems to respond to 32-36 (decimal) and 160-163 (decimal). Document the actions that happen when using these macros.

These seem to be things like "always sway" "movement on powerup" etc....

We have OSC, all we need is something to calculate rotation of shoulder joints against torso, and pelvis to head. That'll get us enough control of the addressable motors to have a good demo.

Whoever gets to this one first, enjoy the media.

After grounding the bus, there's a chance the master node may be listening as a slave node on the I2C bus. Since the buttons are wired to the chip that normally runs as the master node, it would be nice to see if we can figure out how to access button data from it.

Reading 12 bytes from device 0x55 gets us back a bunch of numbers. The chips onboard the keepon do this command once every 15ms, so there's probably something important in there.

Known: The last byte is the position of the forward/back bend motor (Device 0x55 Address 0x2)

Most of the proof of concept work has happened using the 3.3v level shifter. See if we can bypass this completely and use a 5v line (handy for no-hardware arduino control)