The raspberry pi, for those living under a rock, is the $25 linux pc that was announced big almost a year ago. It has a 700Mhz ARM CPU, 256MB RAM and an OpenGL ES capable GPU. To enable hardware hacking it comes with lots of GPIO pins. All in all about the performance of a premium smart phone from three years ago. But at $25 !!! The primary focus are school children, and the foundation wants to bring the fun on computing back to the children. Like every geek who read about it, I couldn’t wait to get one. First, the launch was scheduled for September or October, then postponed to February. The foundation decided they would outsource the shipping to some big electronics companies. They told them that a lot of people would try to get one of the first 10’000 boards, but still they weren’t prepared at all. The websites of the pi foundation as well as farnell and rs components were down the entire day. I got up earlier that day, hoping to be amongst the lucky ones. Later I signed up for a pre order somewhere in the queue for an upcoming batch. As with the first batch, each person could still order only one board. Then about a month ago, I received a mail indicating that it was time to place the order. And today I finally received it. Continue reading “Raspberry Pi – at last”
I wanted the robot arm to be a bit autonomous from the computer, and I thought the bifferboard should be powerful enough to drive it. So I wanted to install ROS onto it. My bifferboard runs debian squeeze, and that means it’s not just a matter of installing the packages as with ubuntu. There is a dedicated wiki page about installing ROS on debian, so I was of the opinion that it can’t be that hard. Actually, I once tried to install ros electric already when the bifferboard was still running debian lenny, and I ran into an infinite loop. I was full of hope that this bug had been fixed now with the release of debian squeeze and ros fuerte. But in fact, the first infinite loop was even earlier this time. And after circumventing an issue in pip with the help of a pip dev, I ran into the one I experienced earlier. I was able to find a workaround this time and reported the issue to pyyaml. The bifferboard has no FPU, and from what I can observe in python no inf and strange handling of nan. Continue reading “installing ros on a bifferboard”
As the name implies, ROS is not just another library to get familiar with. It is an operating system for robots. That is also quite different to a traditional operating system. As I didn’t want to learn a whole bunch of stuff first, I learn about the concepts and facilities as I move along.
After I modeled the robot arm with a urdf xml file, and it moved in the simlator, I wanted to connect ros to the physical arm. I found some tutorials for rosserial on how to connect to an arduino. So, I adapted these examples to the robot arm. The microcontroller board has many similarities to an arduino, but some things are different. First, I compiled the firmware. I had to copy some files from rosserial_arduino, and modified them accordingly. Hooking up the servos as ros subscribers is actually quite easy. The arduino examples use a standard python script on the computer. It looked as if I could use the same. But the robot arm only runs when the RTS level is high. As most libs and programs don’t do that by default, my robot arm did nothing. So, I copied some scripts from rosserial and modified them. In the process I learned about the statserial program that displays the status of the different serial pins. Now, the arm moved to the initial position and waited. Meanwhile I tried to connect to it with the modified python script, but I still got “Lost sync with device, restarting…”.
Another project that I had in mind for a while was to experiment with robot arm path planning and inverse kinematics. If you don’t know what that is, think about how robot arms could be programmed. The simplest form would be capture and replay, in which you have a controller which which you record how you manually move the joints. The robot can then replay the movements. We humans have developed a good intuition for moving our body parts and grasping, but when it comes to formally describing what you do with the joints of your arm, it quickly becomes difficult. My younger son is in the phase of learning to grasp right now, and it’s amazing to see how the eye arm coordination evolves. The second approach would be to program it like a CNC milling machine with something like G-codes. This is a bit more general and more exact, but it’s also more difficult to do collision avoidance. And it’s complicated to calculate as most joints tend to be revolutionate. Both these approaches are only suited for repetitive tasks often found in industry automation, but completely unsuited for robots in dynamic environments. Now with inverse kinematics, you can tell the robot where the arm should move to in cartesian coordinates, and it does all the arm geometry calculations and positions the gripper to the correct position in the desired orientation. Maybe there are obstacles in between the current and the target position. To navigate around these, you also need path planning. That is usually done in configuration space. Real robots have also to care about dynamics such as inertia, but I won’t go that far.