Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Hacking the Tux Droid

Posted by Zonk on Sat Mar 15, 2008 06:33 PM
from the cutest-robot-ever dept.
Rockhopper writes "Ars Technica has a combo review/hack guide for the Tux Droid, a programmable penguin. 'Tux is completely programmable at practically every level, and all of the source code of the firmware and software used by the droid is available from Kysoh's version control repository. There are several ways to program the droid's behavior, ranging from modifying the firmware to coding a gadget in Python.' There's a sample Python script that will cause Tux to speak IRC messages out loud when the user's name is mentioned."
+ -
story

Related Stories

Submission: Hacking the Tux Droid by Anonymous Coward
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • by Anonymous Coward
    attempt of Linux to enter the porn toy market. Sqwuaak!
  • Tux' voice (Score:4, Interesting)

    by Ethanol-fueled (1125189) * on Saturday March 15 2008, @06:38PM (#22762186) Homepage
    I wonder if any hacks include changing the Tux Driod's idiotic voice. Imagine how much cooler the Tux Droid would be if it sounded like Clint Eastwood or even Shaft!
  • I, for one, welcome our robotic Tux overlords.
  • Yes but... (Score:5, Funny)

    by Hatta (162192) on Saturday March 15 2008, @06:43PM (#22762198) Journal
    Does it run Linux?
  • Dude, seriously?

    FTA:
    "After installing the packages, I had to reboot my computer to get the Tux software daemons to start."
      • Re:Seriously? (Score:5, Insightful)

        by sumdumass (711423) on Saturday March 15 2008, @07:21PM (#22762382) Journal
        Th problem with rebooting to solve problems is that it doesn't solve the problem, it just lessens the symptoms. In the windows world, the problem was typically memory management. But just like in the linux/BSD world, it can be other things like programs having rogue functions with unintended consequences when other programs or services are running.

        Anyways, Rebooting doesn't fix the problem, it only removes the symptom which mean you should still look for the cause whether your running windows or linux. In linux, or any *nix stile OS, there should be little reason to restart the system because of something your doing. It is just designed that way.
        • Re: (Score:3, Interesting)

          Th problem with rebooting to solve problems is that it doesn't solve the problem,

          That depends on the problem, there are dozens of easy ways to mess Linux up in a way that a reboot will fix the problem.

          Simple example, take a USB harddrive, make LVM on it and then unplug it and then try to plug it in again. LVM thinks the thing is still at /dev/sde and reports read errors when you try to access it and even when you try to deactivate the volume group, plugin it in doesn't fix the problem because it is now /dev/sdf, sde is busy with being a dead zombie in the kernel internals. How to fix

          • Simple example, take a USB harddrive, make LVM on it and then unplug it and then try to plug it in again. LVM thinks the thing is still at /dev/sde and reports read errors when you try to access it and even when you try to deactivate the volume group, plugin it in doesn't fix the problem because it is now /dev/sdf, sde is busy with being a dead zombie in the kernel internals. How to fix the issue? Simple, you reboot. Maybe there are other alternatives on how to fix the problem, but reboot is by far the mos

            • I imagine you would only have to wait a few minutes so as the mount process would time out.

              There was no mount process, because the drive was already unmounted long ago. It was LVM that still kept its old on the device and wouldn't want to let it go. And restarting that did to nothing to fix the problem. Might there be a way to fix it without the reboot? Maybe, but it simply wasn't worth to time to find out, because it was a clear problem with a clear solution: reboot.

              rebooting only clears the symptoms

              No, it clears the *problem*. The problem is that Linux has gotten into a confused state, reboot puts things back into order. Sure

              • There was no mount process, because the drive was already unmounted long ago. It was LVM that still kept its old on the device and wouldn't want to let it go. And restarting that did to nothing to fix the problem. Might there be a way to fix it without the reboot? Maybe, but it simply wasn't worth to time to find out, because it was a clear problem with a clear solution: reboot.

                Lol.. No rebooting isn't the solution. As soon as you recreate the situation, you have the problem again. So the problem is remo

                • Your car analogy misses the point, so here another one:

                  Your car runs out of fuel because you forget to refuel it. You already know that you should have refueled it earlier and your fuel indicator pointed out the lack of fuel correctly, but you forgot to do so for some reason. Now you can think about what that made you forget it, but none of that thinking will make your car drive again. The problem isn't that you forgot it, but that you are stuck with a car without fuel. You fix that problem by filling new f
                  • Your missing the forest for the trees. In the running out of fuel episode, lets say the problem is that some one is siphoning the gas from the car as you sleep. So you get up in the morning thinking you have a full tank and it runs out on your way to work. Sure putting gas back into the car will get you going but until you stop whoever from stealing your gas, you are going to constantly be running out. The problem isn't that you running out of gas, it is that something is causing you to run out of gas. it h
                    • You still completly miss my point.

                      And no, rebooting didn't fix the problem.

                      Symptom: USB drive doesn't work after plugin it in
                      Problem: Linux device names got messed up and LVM got stuck
                      Cause: Me unpluging it without shuting down the VG
                      Fix: Reboot

                      Now of course a patch to prevent Linux getting into a confused state might be nice or me just remember to shutdown the VG, but none of that will make my USB drive work again. Reboot is the only that will bring Linux out of the confused state again. Reboot fixes the problem, not rebooting leaves Linux in an

                    • Symptom C: USB drive doesn't work after plugin it in
                      Symptom B: Linux device names got messed up and LVM got stuck
                      Cause A: Me unpluging it without shuting down the VG
                      Fix: don't do A and Reboot to clear the symptoms B and C

                      There, fixed that for you.

                      Lol.. You are finally in agreement with me and fail to realize it. You incorectly listed a symptom as the problem though. You attempt to claim that rebooting fixes the problem when it fixes the symptom. That is the point. Now if you don't unplug the drive without s

                    • How do I execute your 'fix' without a time machine? 'A' already happened and there is nothing I can do to undo it, other then just accept that it happened and reboot. Even worse, there is also *nothing* I can do to make sure that 'A' never happens again. I can try to remember it, teach others about it, but as long as human do it, they will forget it sooner or later.

                      Now you could of course argue that the fix with reboot isn't a true fix, but more workaround, and I could agree with that, since it only fixes t
                    • How do I execute your 'fix' without a time machine? 'A' already happened and there is nothing I can do to undo it, other then just accept that it happened and reboot. Even worse, there is also *nothing* I can do to make sure that 'A' never happens again. I can try to remember it, teach others about it, but as long as human do it, they will forget it sooner or later.

                      Lol.. You realize you are arguing something that has already been answered. Your reboot, as I originally stated only clears the symptoms, the

          • Other example, every few dozens reboots my computer tends reorder the USB device names . . . Fix? Again, reboot. USB just happens to be not 100% deterministic and when it does something different, reboot can fix it.

            Wow, that's the worst example ever. A reboot is what caused the problem in the first place. Yes, another reboot may fix it (but as you say, USB is not 100% deterministic, so it may not fix or may even make it worse).

          • > take a USB harddrive, make LVM on it and then unplug it and then try to plug it in again.
            [snip]
            > Next time one should of course remember to vgchange -a n the volume group before unplugging

            No. It should just work. The user shouldn't have to remember anything. Just pull the drive out, and later put it back... and the system should be smart enough to figure it out.

          • If we cold understand the human body like we do man made logic circits and software that runs on it, we would have no disease without a cure. The problem is two fold here, One is that the human body is intricately more complicated then a computer or software that runs on it, the second is that medical professionals make more money with you coming back instead of curing you and sending you on your way. How much of each is at play is subject to interpretation.

            But on another note, Medical doctors only do this
      • So check your /etc/init.d for the startup scripts. Anyone who runs linux should be able to do that.
  • Can you make it speak swear words? That'd rock.
    • Can you make it speak swear words? That'd rock.

      Why the hell would you wanna do something shitty like that, fucktard!

      -1 Flamebait

               
  • by bobdotorg (598873) on Saturday March 15 2008, @07:14PM (#22762340)
    When I told it to get the Gentoo wireless drivers to work properly on my old laptop, it ran across my desk, and flipped me off as it started humping my Opus doll.
  • by Chris Tucker (302549) on Saturday March 15 2008, @07:39PM (#22762440) Homepage
    "Your plastic pal who's fun to be with!"
  • Non Programmer (Score:3, Interesting)

    by Barkmullz (594479) on Saturday March 15 2008, @07:53PM (#22762490)

    Being a network and security kind of guy, the first thing that went through my head was:

    - Finally, a fun way for me to really learn some Python


  • I didn't know. http://www.thinkgeek.com/geektoys/rc/9df0/ [thinkgeek.com]
  • by gradedcheese (173758) on Saturday March 15 2008, @08:32PM (#22762614)
    I was curious so I looked up the embedded system inside the robot, it's an 8-bit Atmel AVR with supporting hardware. I figured that the Tux-shaped robot would at least be running Linux internally, for example they could have used a Gumstix board or the like. That said, AVR development is pretty fun (and you get to use gcc rather than some vendor tools) and this thing looks like a neat embedded toy.
    • Re: (Score:3, Insightful)

      Gumstix boards are expensive. Their online store sells the cheapest barebones one for $99. ThinkGeek sells the Tux Droid for $99. The goal of an embedded system is to use the resources as efficiently as possible, with the smallest footprint possible. Embedded linux for this application would certainly have the *WOW* factor, but would be overkill and the additional hardware requirements would raise the price of the Tux Droid.
  • Looks like the open source world's answer to Microsoft Barney for Windows.

    We need to do better than this.

  • The damn thing doesn't even move around. It just pivots in place, etc... There's absolutely no way you can mount a megawatt laser to this thing, and get the respect of your enemies.
  • by madsdyd (228464) on Sunday March 16 2008, @01:14AM (#22763624)
    And, have it scream, while flapping its wings, "Dudes! <devname> broke the build with commit <svnrev>!", whenever appropriate.

    I reckon it will be no problem getting the bosses to pay for that :-)

    Or, "its time for lunch", "remember the team meating in 5 minutes", and other stuff.

    I am halfway serious, actually. :-)