Welcome to my everlasting endevour... to create the perfect robot arm.
I have created many small robot arms over the years (see minirob arm and mobilearm), but this one is by far the most ambitous.
I will catalogue what I have so far.
I have purchased a gumstix 400MHZ cpu core for the robot controller. This should be powerful enough to calculate robot position values and drive the motors. I will conduct extensive tests on the platform to test plausability.
At the moment I have connected the Gumstix I2C to a velleman K8000 board. This has given me some limited ability to debug output and test routines.
To enable communication betweent the gumstix and the K8000 I wrote a /dev/velleman driver which was later adapted for communication with an i2c servo (detailed later)
I have also adapted the i2c drivers to enable me to communicate with the servo.
for the servo driver I have decided to evaluate the project started by Mike Thompson at www.openservo.com Openservo.
This platform is an ever evolving servo controller based on the Atmel ATTiny45 to enable connection between the I2C bus and the motor. It enables precision control over the motor using PID algorithms.
The use of openservo as in its current form is perfect for the small end motors on the robot arm without modification, but the larger 3A motors will need a large H-Bridge driver chip to enable connection between the Attiny and the motor.
Possibilities for this large H-Bridge driver include using 4 FET's, or an integrated driver such as the L6203 or 18200. I will explore these at a later stage in the project.
I also have a development kernel driver for connecting multiple servos to the i2c bus for registration in either the /dev filesystem or /proc. The interface allows reading of values to the servo, as well as reading large amounts of information from the servo.
Hardware is divided into three sections, Host controller hardware, Intermediate controller hardware, and the robot hardware.
The layer between the intermediate controller and the host controller is varied. There are various connection methods that the gumstix supports, enabling a software layer to be bound to manyy interfaces.
As detailed above, I will use the Gumstix platform for the hardware interface between the PC/Host controller and the robot interface. There are good reasons for using this controller, here a but a few:-
Interfacing this hardware to both a computer, and the robot hardware is fairly trivial with this board.
With the system having an I2C bus, it is easy to connect to I2C devices, such as the Openservo.
The controller for the servos in this application fall into two distinct categories. There is the H-Bridge implementation section, and the H-Bridge controller.
I am using the Openservo project as a template for interfacing between the I2C bus, and the H-Bridge. This project is dedicated to the open source implementation of a servo controller. This is almost perfect in the application at hand, and only requires making the H-Bridge driver circuit handle more voltage and current.
The Openservo project has many features applicable to the goal of this project
I will be using 12V 4A motors for the Arm segments of the robot, and smaller 12V 2A motors for the small axis.
The hand axis are custom modified heavy duty metal servos, in a hobby servo form factor.
The software can be broken down into several section. there is the Host control software, and the embedded intermediatry controller.
The host controller can implement any interface to the robot it wishes to. I already have code to model the robot in 3d using OpenGL, and also WindowsCE applications.
The embedded Gumstix controller has a more complex system inside.
The software controller of the robot is based on a state machine with all of the variables of the robot inside a working simulation.
There are 2 levels to the embedded code:
The core kernel controller
This handles all of the scheduling of the components of the robot. This allows non locking interfacing with the robot /dev filesystem in Linux.
The kernel controller allows multiple threads to be run, each with its own thread properties. A thread can be set to trigger once, on certain conditions, and periodically.
A thread can perform many functions, including the communication between the sensors on the I2C bus, to writing a file to the system disk.
By default the kernel controller has only two threads, a logging thread, and a communication thread.
The higher level interface
There is a layer that sits atop of the kernel interface, composing values form the threads and tasks, and coordinating the robot and its axis.
The layer communicates with the host controller, and passes all data to the algorithms.
Depending on mode selected, there are certain condition triggered.
These different modes allow for Inverse Kinematic calculation (using the RobOOP library) for cartesian space coordinates, and also simple axis control.
This will be covered in a later article, as it deserves a section of its own.
I will detail the drivers in phase II of "Robot Arm II". I will also need to think of a name for it.