PERTINENT INFORMATION - Q-Division-2019-2020-Even/Team-5 GitHub Wiki

GATHERING PERITINENT INFORMATION:

This project involves designing and building a mobile robot capable of human-like behaviors. The means to which these behaviors are achieved are contained in three aspects of the robot‟s design. The first is a mobile base that allows the robot to navigate through an indoor space. The second is a head and neck capable of producing several human-like gestures coordinated with speech. The third is an arm and hand assembly used to supplement the robot‟s gestures and allow it to grasp and move objects. Each of these design aspects is integrated to complete the first phase of the project and produce a platform for further research. Subsequent phases will involve using existing artificial intelligence, vision, speech, and dialog software to expand the capabilities of the robot. Also, the robot will be used to research a new type of artificial neural network at Ohio University.
This paper details the design and development of the arm and hand assembly within the first phase. The arm and hand, henceforth referred to as arm, are designed to meet the following requirements. First, it must have the ability to grasp an object and place it in a different location. Second, it must be similar in scale to that of a human arm and be able to replicate similar motions. The final design should be made with standard components, such that it could be easily reproduced and mirrored to create left and right versions. Finally, the arm should be easily mounted to the mobile base.
The scope of the first phase of the arm‟s development is defined by the following limitations. The arm is built with as many un-modified components as possible. In addition to reducing the amount of time necessary for fabrication, this facilitates the final design being easily reproduced. The ability of the arm to move an object is primarily symbolic. With this in consideration, an object with a negligible mass is chosen. This reduces the torque requirements for the arm‟s actuators and allows the overall design to be built to a larger scale. To simplify the software design, each joint on the arm will be manually controlled. Although future phases of the project will likely require more sophisticated motion control, this simplified approach allows the robots actuators and ranges of motion to be controlled and tested in a straightforward way. As a first step to higher levels of motion control, the forward kinematic equations for position are included in the first phase.
With these limitations in mind, the details of the projects are broken down into the following. The mechanical design of the arm deals with its physical construction and range of motion of each joint. System modeling relates the position of the hand to the angles of each joint in the arm (kinematics). Software design includes the programming methods for commanding actuators to move a joint to a specified position in addition to a description of the programming environment. The electrical components encompass the hardware necessary to control and power the system, actuators, and the devices to send command signal to them. The first step is to complete the mechanical design, the details of which are described below.

Mechanical Design

This project involves using an existing head and neck and modifying an existing mobile base. The arm, however, is designed and built from scratch. For this reason, the majority of work on the arm in the first phase revolves around its mechanical design and construction. The first step in the mechanical design of the arm is to define its degrees of freedom. A degree of freedom, or DOF, is an independent displacement associated with a particular joint. Joints can be ether prismatic or revolute, or both. Prismatic joints are capable of linear motions while revolute joints are capable of rotating. In this case each of the arm‟s joints is revolute, and thus, each degree of freedom is a rotation. Each of these DOFs is controlled by an actuator.
The human arm is considered to have seven degrees of freedom. These consist of three rotations at the shoulder, one at the elbow, and three rotations at the wrist. The actuators that control the shoulder and, to a lesser degree, the elbow have to carry the load of the entire arm, hand, and payload. These actuators must be capable of producing substantially greater torque than actuators at other joints. To reduce the number of high-torque actuators required, the shoulder is designed with only two DOFs. Although the wrist does not have to carry a high load like the shoulder, space at this point on the arm is limited. For this reason, the wrist is given only two DOFs. This leaves a total of five degrees of freedom for the arm instead of seven. The human hand has twenty seven degrees of freedom, most of which are associated with the fingers. To grasp a simple object, the motions of the fingers are not needed. This assumption allows the hand to be designed with one degree of freedom, thus greatly simplifying the design. A simple representation of the arm is shown in the Figure 1 below. The red arrows represent the axis that each DOF can rotate about. Although the hand is shown, its DOF is not labeled.

Figure 1: Robot arm’s degrees of freedom.

As mentioned above, it is important that the final robot design be easy to reproduce and mirror. This is facilitated by using TETRIX components whenever possible. TETRIX is a component system originally designed for use in high school robotics competitions. The system consists of a variety of prefabricated aluminum components that are designed to be easily modified and connected to one another. Also included are high torque DC gear motors, servos, and motor drivers. These components are compatible with the LEGO Mindstorms system. The LEGO system not only includes components for building robots, but includes a series of Plug „N Play

sensors and peripherals in addition to a controller and programming environment. Together these systems allow a designer to quickly build robot prototypes with little or no fabrication. The details of the LEGO controller, programming environment, and electronic components are described in later sections. Figure 2 shows the basic TETRIX robotics kit.

Figure 2: TETRIX robotic kit.

Although the use of TETRIX components reduces the effort and time required to design and build the system, not all of the components were initially available. Thus, the arm needed to be designed before the components were acquired. The Solid Works CAD tool was used to accomplish this. Solid Works is a modeling and simulation environment capable of representing three dimensional shapes in space in addition to material properties. An online CAD library was used to acquire models of most of the TETRIX and LEGO components. These individual models are combined in an assembly that defines the spatial and kinematic relationships between them. The resulting virtual assembly is used to evaluate the moments of inertia, mass, volume, physical dimensions, etc. at a component or system level. Also, this assembly is used to simulate motion between the components. This allows the designer to check for collision between parts, analyze the range of motion of the entire system, and visualize its performance before anything is physically made. Approximately eight design iterations were investigated with this tool before parts were ordered and very little was changed from the CAD model once it was actually built. Figure 3 shows the final model of the arm without any custom fabricated parts.

Figure 3: Solid model of robot arm and hand assembly.

This model does not include some of the hard ware necessary to complete the assembly in addition to the hand. Figure 4, shows the complete TETRIX assembly and hand. Figure 4: Final TETRIX robot arm and hand assembly.

In addition to the stock TETRIX components, welding rod was used to fashion the fingers of the hand. The plate that the fingers attach to was also fabricated. A list of the modified TETRIX components is in the appendix.

Electronic Components

The electronic components used to operate the arms consisted of two electronic motors, four electronic servo motors, one motor controller, one servo controller, and the NXT brick. The motors were used on the elbow and shoulder joints to provide more torque and stability while servo motors were used to control the hand, wrist, and arm rotation. All these components are part of the Lego Textrix Robotics division. Using the Tetrix parts along with the NXT brick allowed for less time spent integrating and developing drivers, because when programmed with RobotC, the drivers and control functions are already integrated into the system allowing for more of a plug-and-play environment. This saved time in developing code for controlling the arm. The main control of out arm is done by the NXT brick. This control unit is run by a 32bit ARM7 microprocessor and an 8 bit AVR microcontroller. It has 4 six wire input ports, and 3 six wire output ports. It also contains a USB port for programming and debugging. It is mainly programmed using the NXT graphical interface language, LabVIEW, RobotC, or NXT++. We chose to use RobotC, which is a subset of the C programming language since that is what our group was the most familiar with. This will be discussed further later on in the report. The RobotC interface allowed us to download and run programs on the NXT unit, and once downloaded could be run directly from the NXT without needing to be hooked to a computer. For our application we were using Tetrix products to interface with the NXT we ran all our components from Sensor Port 1 of the NXT. The NXT allows up to four controllers to be daisy chained to each sensor port. These controllers can be a combination of servo controllers and motor controllers which will be discussed later. Any sensor that will be used for additions for arm control will also be plugged in to the NXT.

The motors we used were Textrix DC motors available from Lego Robotics. The motors run at 152rpm at full power and provide 300oz-in torque and require 12V to operate. Within the software the speed can be controlled by setting the percentage of the motor speed to lower the RPM of the shaft. This gives the motors more versatility when used in projects where more torque than can be provided by a servo is needed, but the slower speed of the servo is still desired. This was useful in our application a servo motor would not have been able to hold up the weight of our robotic arm, but we still needed slower movement for a more realistic appearance and allow more control for the user. The disadvantage of using motors in this situation is they are heavy and more difficult to mount than a servo would be. We installed encoders for position control, but we did not use them for this part of the project. The operation of the encoders will be talked about later in the report. The motors are powered and controlled using a HiTechnic DC motor controller. This motor controller interfaces the motor with the NXT brick as well as providing power to the motor itself. Each motor controller can operate two 12V Tetrix motors as well as interface with motor encoders which will be discussed later. It is this motor controller that allows the motor speed to be adjusted by changing the power level supplied to the motor by using an internal PID algorithm.

Encoders are installed on the two motors used on the robot. These encoders are made by US Digital. They are used to allow position control of the motors so they can perform similar to servos. The encoders used are optical quadrature encoders. These encoders use two output channels (A and B) to sense position. Using two code tracks with sectors positioned 90 degrees out of phase, the two output channels of the quadrature encoder indicate both position and direction of rotation. If A leads B, for example, the disk is rotating in a clockwise direction. If B leads A, then the disk is rotating in a counter-clockwise direction. The encoder also allows the system to use PID control to adjust the speed of the shaft.

The servo motors used were three HS-475HB servos and one HS755HB all made by Hitec. Both servos are 3 pole with karbonite gears that can be run at 4.8V or 6V. The 475HB provides about 80 oz-in of torque and the 755HB provides 183 oz-in of torque. The 755HB is a larger servo than normal is used with the Tetrix system, but the servo wire is the same for both servo types, so they can both be used with servo controller. The downside of this servo type not being available for the Tetrix system is that there is not mounting hardware available so a mount had to be fabricated to attack the servo to the Tetrix stock parts. The servos have a range of 0 to 255 so they give you excellent position control. The motors inside the servo only hold position when powered so when the power is removed any weight bearing servos release. The wrist on the robot is an example of this. When the program is running the wrist servo supports the hand, but as soon as power is removed or the program is ended the hand falls to one of the servo extremes. Like the motors, in order to interact with the NXT device the servos must attach to a HiTechnic servo motor controller. The servo controller requires a 12V supply and it divides this down to 6V to operate the individual servos. The servo controller can hold up to six servos together, and like the motor controllers the can be chained together to allow the use of more servos than on controller could handle.

Software

The programming of the arm movement was done using RobotC language. RobotC was developed by Carnegie Mellon University and is a subversion of the C programming language. It uses the same syntax as C but a does not have access to the same libraries, so the command availability is somewhat limited. There are specific libraries for some aftermarket parts, and libraries can be made to incorporate new parts for use with the NXT. The PSP-Nx-lib.c library was used in order to use as PS2 controller to operate the arm.
The software to control the hand can be broken up into three sections: controlling the DC motors, controlling the servos, and integrating the PS2 controller. The code for each was tested prior to being compiled into the final program. We will start with describing how the DC motors are programmed, followed by the servos, the controller integration, and finally how the finished control program works.
The software allows the DC motors to be turned on, turned off, set the power level as well as allowing encoders to be used. In order to use the motors the configuration coding should be entered at the top of the top of the program. The line “#pragma config(Hubs, S1, HTMotor, HTMotor, HTServo, none)” sets sensor port 1 (S1), and configures it to have two motor controllers and one servo motor controller chained together. After that each hub must be set. To

configure a motor you use the line “#pragma config(Motor, mtr_S1_C1_1, motorD, tmotorNormal, openLoop, reversed, encoder)” this line sets the first controller (C1) on sensor port 1 (S1) as a DC motor plugged into the motor 1 slot. The command motorD, sets the name of the motor to be used in the program (motorA, motorB, and motorC are designated for NXT motors) and tmotorNormal sets the motor in normal mode. The motor can be set in openLoop or PID to use the internal PID controller. The PID mode can only be used if an encoder is attached to the motor and activated. The motors can also be switched between forward and reversed modes in this line. Once these lines at entered it allows you to use motor control commands.

Performance Structural The mechanical arm is built from almost entirely pre-fabricated Tetrix aluminum components, two DC motors with gears, several small-scale servos, and is built to full-scale human arm size. Due to this, it takes a minimal amount of torque to cause vibration in or possibly warp the base components. This means that the mechanical arm cannot carry large amounts of weight. It is estimated that it can pick up slightly less than three pounds at full extension. However, the design is robust and allows large range of movement without detrimental effects on the structure, thus providing the possibility for a very human-like interaction with this arm.

12

Position Control

Currently there are encoders attached to the two DC motors which control the „shoulder‟ and „elbow‟ vertical movements however they are not used. The encoders cause difficulty with the motors because the motors resist instantaneous position correction and they lock-up. Currently all position control is manual and user-operated through a RF wireless joystick controller. Object Grasping The hand attached to the mechanical arm is designed to mirror a human hand. Currently it only has one DOF, its ability to open and close by moving the thumb. This however is sufficient for grasping and picking up objects. The movements are relatively slow so that they are somewhat more realistic. Additionally, if the servos speed is increased accuracy is lost.

Future Work

Sensors Future work that can be performed on this mechanical arm includes adding sensors. These could include sonar range finder, stereo (two) camera vision, or even an experimental smell detector. This would allow automation of the entire robot Specify End-effecter Position Additionally, and more specifically for the mechanical arm, future work could involve solving the inverse kinematic equations for all degrees of freedom in the arm. This would allow the user or an automated intelligent program utilizing sensors to specify a position and orientation that the hand should be in. All the angles of rotation for each motor and servo would be automatically calculated and moved to that position. Trajectory planning With the addition of sensors, the arm and hand could potentially utilize trajectory planning. This would entail sensing an object coming toward the robot, calculating its speed and trajectory, and moving the arm and hand to a position along that trajectory to potentially deflect or catch the incoming object. The movement of the arm and hand would have to be sped up and position control accuracy would have to be increased for this to be possible. Genetic Search Algorithm As long as memory in the NXT brick allows, genetic algorithms could be implemented to allow for room mapping and searching. This would allow the robot, and more specifically the arm, to know the position of objects in the room and potentially interact with them.
Image processing Image processing would be an essential upgrade with vision sensors so that the incoming data could be interpreted properly. Intelligent processing would allow more accurate readings and would provide optimized responses.

Conclusion

Overall, the goals of the first phase of the robot arm have been meet. The final assembly is made almost entirely of stock TETRIX components. The parts that were modified were done in such a way would be easy to reproduce. Although the method of motion control is limited in the current state, it serves as a strong foundation on which to test the performance and interface of the electronic components. The forward kinematic equations have been developed and the process has been well documented for future research with this robot.