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.
The first arm I got was a Playtastic robot arm from pearl. You can find lots of references to this arm on the internet. It comes under various names. It’s also available with a USB interface for programming, so they say. But it has one mayor problem that I didn’t expect: It has no positional awareness.That means you don’t know what state it’s in, especially when you switch it on. The programming they refer to is effectively just capture and replay of the timing how long you switch the motors on. You can easily imagine how inaccurate that is, even if you had an endstop to go to a home position after turning it on. The arm doesn’t have endstops, so you would have to go to exactly the same position every time before switching off, or you would drive every motor a full move length to one directory, but that would be pure abuse. I found some posts of people mounting poentiometers to each joint, or measuring the current of each motor so exactly to count the revolutions. I thought about doing that for a while too, but I couldn’t convince myself that this would lead to a good solution. So the arm is waiting now for my sons to grow a bit older to play with it. That’s also what it really is: a toy.
The next arm I got was one with hoby servos in each joint. It’s an Arexx mini from reichelt. Servos only offer open loop control, and it’s less stiff than the former arm, but that’s enough for my purposes. This device is a totally different experience than the one from pearl. If you don’t know how to program, you won’t have much fun with it. Although it costs almost twice as much, I would say it has much better value for price. Now Conrad sells the arm in switzerland as well, but for twice the price you pay when ordering from Germany. It comes with a microcontroller board, a second board with some buttons to test the arm as well as an FTDI board. You can load new programs onto the microcontroller through a usb cable and a java program. I generally don’t like programs luring around somewhere on my harddisk, so I created debian packages for ubuntu. Also, the RACS program for controlling the arm through some sliders on the computer is only available for Windows, so I implemented a small, incomplete clone. You can install my packages with the following commands:
sudo apt-add-repository ppa:richi-paraeasy/ppa sudo apt-get update sudo apt-get install arexx-robotloader arexx-robotarm-examples arexx-robotarm-racsqt
I learnt a few things in the process of creating the packages. For one, the examples came with gnu makefiles. I found them hard to read and change, and they compiled the library sources in place. As my package installs the library to a system location, the user doesn’t have the rights to write there. So, i went looking if I could use cmake to cross compile to the ATMega. It turned out to be almost as easy as the usage of cmake in general. I created a finder script and a setup script for the robot arm. After all, for the microcontroller part of my RACS clone, the CMakeLists.txt looks as imple as this:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8) PROJECT(RobotArm_RACSQT_uc) FIND_PACKAGE(ArexxRobotArm REQUIRED) INCLUDE(arexx_robot_arm_crosscompile.cmake)
ADD_ROBOT_ARM_EXECUTABLE(RobotArm_RACSQT
RobotArm_RACSQT.c
)
INSTALL(FILES ${CMAKE_CURRENT_BINARY_DIR}/RobotArm_RACSQT.hex DESTINATION ${CMAKE_INSTALL_PREFIX}/share/robotloader/examples/racsqt)
While making the RACS clone, I also learnt how well cmake interoperates with Qt. I can design the GUI in the QtDesigner, and let cmake handle the rest: https://github.com/ulrichard/robotloader/blob/master/racs/qt/CMakeLists.txt
To reset the robot arm, you have to switch the RTS line on for a moment, and then switch it back off again. It’s not as easy as enabling hardware flow control for a moment. So far, I found no way of toggling this single line with boost::asio. So I ended up fiddling with the open connection directly through ioctl.
At first I thought of coding the path planning and collision avoidance all by hand. But before I started doing so, I learnt about ROS (Robot Operating System). I heard of it before, but only now I had a closer look at it. I’m still reading through the documentation. The urdf file is probably far from finished, but I can already launch a simple simulator that shows a robot arm that looks more or less like the physical one, and move the joints.
https://github.com/ulrichard/robotloader/blob/master/ros/arexx_robotarm/arexx_mini_urdf.xml
My wife always ask me: “what do you want to do with that robot arm?” Usually I just say “learning and all sorts of stuff”. Obviously that’s not specific enough for her. But when I told her I might make a chess playing robot, that sounded interesting enough for her. Well, that’s far off at the moment, but the really interesting part is just about to start…
Leave a Reply