The Stats:

64 bit Fedora 9 Beta (though I saw the Eye issue while using Knoppix, and tuxgi)
1.3.1 rc1
Haven't updated the firmware, as I don't know what might go wrong being on 64bit

The first problem; no response when trying to communicate with Tux.
Let me show you what does work:  My commands then followed by the tuxd debug results:

>>> tux.cmd.raw(MOVE_MOUTH_CMD,2,0,0)
2
>>> tux.cmd.raw(BLINK_EYES_CMD,2,0,0)
2
>>> tux.cmd.raw(WAVE_WINGS_CMD,2,7,0)
2

debug: CMD: 00 41 02 00 00
debug: CMD: -> ACK
debug: head motor for mouth 1
debug: mouth open position 1
debug: mouth close position 0
debug: mouth close position 1
debug: mouth open position 0
debug: head motor for mouth 0
debug: CMD: 00 40 02 00 00
debug: CMD: -> ACK
debug: head motor for eyes 1
debug: eyes open position switch 1
debug: head motor for eyes 0
debug: head motor for mouth 1
debug: eyes open position switch 0
debug: head motor for mouth 0
debug: CMD: 00 80 02 07 00
debug: CMD: -> ACK
debug: wings motor backward 1
debug: wings position switch 1
debug: wings motor backward 0
debug: wings position switch 0

So, the above is great.  It shows that I can issue commands and that Tux understands them Now:

tux.cmd.eyes_close()
debug: CMD: 00 38 00 00 00
debug: CMD: -> ACK

(And the eyes don't go closed)

>>> tux.cmd.flippers_up()
>>> tux.cmd.flippers_down()
>>> tux.cmd.flippers_up()
debug: CMD: 00 39 00 00 00
debug: CMD: -> ACK
debug: CMD: 00 3a 00 00 00
debug: CMD: -> ACK
debug: CMD: 00 39 00 00 00
debug: CMD: -> ACK

(No flipper movement)

Rotation also has the same effect.  The one command that does work is mouth movements.

More about mouth movements... First lets close the eyes:
>>>tux.cmd.raw(BLINK_EYES_CMD,1,0,0)
2
debug: CMD: 00 40 01 00 00
debug: CMD: -> ACK
debug: head motor for eyes 1
debug: eyes open position switch 1
debug: head motor for eyes 0
debug: eyes closed position switch 0

Now the eyes are closed, and the mouth is open (from a previous command)
debug: CMD: 00 41 01 00 00
debug: CMD: -> ACK
debug: head motor for mouth 1
debug: mouth open position 1
debug: eyes open position switch 0
debug: eyes closed position switch 1
debug: mouth close position 0
debug: head motor for mouth 0

So I send a command to close the mouth (which it does) and the eyes pop open.  I've had this also happen when the eyes are closed and the mouth is opened.

Those are the bugs I've encountered so far.  This could be a firmware issue, but I'm not sure.  I've also had this same problem when I closed the eyes, and used the tuxgi to exercise Tux (the eyes pop open).

Cheers!

--T

Oh, one other issue.  Here is what I am doing, and here is the tuxd output:

Push & Hold left flipper
debug: left flipper pushed

Push & Hold head button
debug: head button pressed

Push & Hold Right Flipper
debug: right flipper pushed
debug: right flipper released

Release Left Flipper
debug: left flipper released

Release Head Button
debug: head button released

Release Right Flipper

Notice the right flipper triggered a push and release event when it was only pushed?  Sometimes it won't trigger any event until released, and then it triggers both events.

-T

One last thing, if you are wondering how I got this to run on 64 bit, I went into the python classes and removed any line that had "OSL" in it.  That way it wouldn't import the libraries, and give me the error.  There were also a few TTS lines that needed to be commented out in the destructor (I think).  Just follow the errors and you should be able to do the same thing.

Haven't updated the firmware, as I don't know what might go wrong being on 64bit

That's exactly where your problems come from. All the extra commands have been added in the latest firmware version. I wanted to finalize all the movements and we added all commands we thought would be useful and not achievable with the simple commands.

So you have to update the firmware. If you don't update the RF, you can't brake your tux whatever goes wrong. You will always be able to enter bootloader mode and reflash again. I think the flashupdater from the beta tuxsetup 1.3 shouldn't reprogram the RF this time, though I didn't try myself so I'm not 100% sure. Jerome could confirm this. Otherwise use tuxup directly.

Cheers,
David