Balancing Bi-pod Robot

Transcription

1 Balancing Bi-pod Robot Dritan Zhuja Computer Science Department Graceland University Lamoni, Iowa Abstract This paper is the reflection on two years of research and development of a balancing sensor that can be used in robots controlled by Lego Mindstorms RCX programmable bricks, in particular a bi-pod (two legged) robot that requires complex balancing maneuvers. The paper covers details regarding both sensor and robot since they are tightly coupled. The balancing sensor design incorporates a set of ideas that have been used previously in certain types of electronic and mechanical devices familiar to everyone, such as the computer mouse and the pendulum. The sensor uses the earth s gravitational pull as the base force for balancing robotic devices. Throughout the two years of development the design for this sensor has been modified and advanced several times for it to be more compact, easier to use and less expensive. These design modifications were necessitated by the type of robot that used the sensor for balancing. The paper discusses in detail the most important advancements and innovative ideas of this project. The main stages of the balancing sensor s development are discussed beginning with the first design that was integrated in a two wheel Lego robot, to another version used in a four legged Lego robot, and finally to a more complex design for use in a humanoid bi-pod robot. The bi-pod simulates a more human approach in balancing since it involves multiple joints with multiple joint orientations. The decisions which affect the bi-pod s motion are based entirely on the readings of the balancing sensor. The bi-pod robot is controlled by two Lego RCX bricks programmed in NQC (Not Quite C), a C like language for Lego RCX robots. There are multiple servo motors that make it possible for the robot to execute precise movements with angle measurement and speed control. The servo motors are directed by two third-party I2C-SC8 servo controllers manufactured by mindsensors.com. Some of the challenges and solutions in using these I2C devices will be discussed in addition to overall problems and solutions using the balance sensor. Future work that incorporates additional features will be discussed.

2 1 Introduction The area of robotics dealing with designs that imitate human behavior with some degree of realism is something that the author has been interested in for a long time. This paper outlines the trials, setbacks and successes on several projects leading up to and including work on a Bi-Pod robot under the constraints of a limited budget and RCX-based robotics. The Bi-Pod robot is essentially a body on two legs, and the goal of this project was to build something that would balance its body independently, that is without human interaction, thus simulating a more human approach towards balancing. Section 2 discusses balancing sensors and some technical details regarding the different stages of the sensor development during this work. This coverage is necessary in order to understand the advantages and/or disadvantages of using these sensors and the reasons to use or not use a specific sensor. Section 3 presents details regarding the I2C and I2C-SC8 devices for servo-motor control. These are third party I/O hardware extensions to the RCX brick. Such extensions are necessary because of the natural limitations of the Lego RCX programmable brick, which will also be discussed. Section 4 is the main section. It covers the most current design of the Bi-Pod robot, including important portions of the source code that controls the Bi-Pod s movements. Section 5 summarizes the major problems and limitations that were encountered along the way and identifies possibilities for future work. 1

3 2 Balancing Sensors A balancing robot obviously requires balance sensors, sensors that detect a change in the 3-dimensional position of the robot body. Three different attempts have been made to achieve the goal of this project, using different categories of balancing sensors. The following sections briefly describe each attempt and the limitations that were encountered. They are in order from first to last sensor development: pendulum balancing sensor, space-ball sensor, and mouse-ball sensor (used currently). The sensor names are those given by the author, named after common mechanical devices that we are either familiar with or that describe the device. All of the sensors are based on the force of gravity. 2.1 First model Pendulum Balancing Sensor A gravity pendulum has a weight on one end of a string, and the other end is held by a stationary object [1]. The earth s gravitational pull affects the weight by pulling it towards the earth s core. This natural phenomenon allows the string position to be perpendicular to earth s surface. The first model for a balancing sensor was based on this principle. To test this model, a simple 2-wheel platform robot was built that could naturally fall forward or backward on its axle. The sensor was placed on its platform body. This turned out to be too extreme of a test environment for this research. Since the author was more interested in walking robots, a simple four-legged robot was built that would have a more stable behavior so that the balance sensor and robot controlling software could be experimented with (Figure 1). This robot was a standing robot, not a walking robot. To tilt this robot, the entire table on which it stood would be tilted and the robot would react to that imbalance. Figure 1: The four-legged robot 2

4 2.1.1 Design and operation The early sketches of the pendulum balancing sensor are shown in Figure 2. The fourlegged robot (only two are shown in Figure 2c) was an early model to test the use of this type of balancing sensor. Figure 2: a) weight, b) rotation sensor combo, c) 4-legged balancing robot The weight (Figure 2a) was attached to the bottom of the rotation sensor combo (Figure 2b) which sat on top of the hollow body such that it had the freedom of motion inside the body (Figure 2c). The junction between the platform and a leg had a simple motorized gear mechanism that would raise or lower the platform at that junction. The programming language used to program this robot was LeJOS, a Java-like language for Lego RCX robots [2] [3] [4]. The author chose to use this language because of his familiarity with it. There were two Lego Rotation Sensors (Figure 2b), one to detect angular range of motion for an X-axis and the other for a Y-axis. Each axis sensor reads positive integer values if rotated in one direction and negative integer for the other. The robot had to be in a balanced position prior to starting the program in order for the rotation sensors to establish zero as a base reading. A simple event loop that polled the readings was used to detect changes in the direction and degree of motion. The X and Y readings and the absolute positions of each leg were used to determine which of the four legs should be raised or lowered to bring it back in balance and keep the legs from topping or bottoming out. There were many variations of the program but the essential idea remained the same: to set the motors in motion in response to the readings and then continue with the event loop, to do the next reading while the motors are in motion from the previous reading Problems encountered It was very quickly observed that this balance sensor would not work if the body of the robot tilted too far. The X axis motion detection limit was 70 in either direction, and the Y axis motion detection limit was 120 in either direction. These limits had do to with the particulars of the design which caused the weight to bump into the inside walls or other structures of the body. Another problem was that the robot had a high reaction speed for responding to rotation sensor readings. The pendulum oscillated continuously and the robot did as well. The two obvious ways to solve this problem was to (1) reduce the robot reaction speed by 3

5 lowering the power of the motors, or (2) to react based on the average of the past N rotational readings stored in a buffer. However it was decided to try a different type of balancing sensor rather than to continue with this one. 2.2 Second model Space-Ball Balancing Sensor To remove the limitations of the Pendulum Balancing Sensor and increase the motion detection space to 360 for the X-axis and Y-axis (hereafter referred to as the horizontal and vertical), the author designed another sensor resembling the Space-Ball, a device created by NASA over 40 years ago for humans to experience weightlessness and often found today in virtual reality environments or carnival entertainment (Figure 3) [5]. Figure 3: Space-Ball Design and operation The degrees of free rotational motion for both horizontal and vertical directions are shown in Figure 4a. The 360 of free rotational motion in either horizontal or vertical direction allow the sensor to detect motion in three-dimensional spherical space. Thus the robot will be able to know at any given time what the position of its body is. Figure 4: a) Space-Ball Sensor b) Space-Ball Sensor Prototype The rules for the robot using the Space-Ball sensor are the same as for the Pendulum sensor. Like the previous model the initial starting position is zero and assumed to be the balanced base reading of the sensor. The main advantage of this sensor was that it will allow the robot to tilt further and know its position. 4

6 2.2.2 Problems encountered All of the problems noted in the previous section would exist with this one as well. A prototype for this sensor was built but it never was fully equipped with sensory hardware, nor installed on a robot. A working version of this sensor never found its way into the robot design because better and more interesting ideas came to mind. 2.3 Current sensor Mouse-Ball Balancing Sensor The Mouse-Ball Sensor is based on a mechanical computer mouse. A mechanical mouse has a rotating ball that is in contact with two wheels, each measuring different axes of movement and by sensing the rotations of these wheels the horizontal and vertical coordinates can be identified for where the cursor should be on the computer screen. This same general principle is used for the Mouse-Ball Sensor. The model needs to measure the degree of rotation for two different wheels. Although the Lego Rotation Sensor was considered for this, it turned out to be unacceptable. In this sensor there is friction between the rotating plastic part and where it comes in contact with the base of the sensor. This friction is unavoidable and it is too much to overcome by any light-weight mouse-ball design. The balancing sensor must be sensitive enough to detect small position changes of the robot body and friction is something that will not allow us to do that. Therefore to eliminate the Rotation sensor s friction, the author designed a sensor that still uses the pendulum approach for balancing and Lego Light sensors, rather than Lego Rotation sensors, for motion detection. A Lego Light sensor has a Light Emitter and a Light Detector. Light sensor readings are based on the amount of light reflection received from the Light Detector so it can count marks on a rotating wheel Design and operation The heavy computer mouse ball is placed and glued inside a plastic ping pong ball, to act as a pendulum where the heavy weight is used to read the balance displacement. The ping pong ball is then placed on top of two rollers covered with rubber tubes rotating the Chopper/Gear, a part found in a mechanical mouse [6]. The rubber covering the rollers is necessary because the plastic Ping Pong ball will slide on the plastic rollers, thus the roller will not rotate for the Light sensors to detect motion. The rollers represent the Horizontal and Vertical motion directions of the Ping Pong ball. The Chopper/Gear is used to detect the direction and speed of a moving Ping Pong ball. The Chopper/Gear that the author designed for this balancing sensor is a modification of one used in a regular mechanical computer mouse, made to fit the size of the Light Emitter and Light Detector of the Lego Light sensor. Figure 5 shows the setup of the sensor. 5

7 Figure 5: Mouse-Ball Balancing Sensor The graphical representation of the meaning of the Chopper/Gear (Figure 6) shows the rotating disk separated in four identical sections. Each Chopper/Gear has two Lego Light sensors that detect the changes in light as the Chopper/Gear rotates. Each section has open wholes that allow the light from the Light Emitter to pass through to the Light Detector on the other side of the disk. Figure 6: Chopper/Gear Each section has decimal values 0,1,2,3 represented as binary numbers 00,01,10,11, where 00 means neither of the Light sensors is detecting light and 11 means both Light sensors are detecting light. Reason for using 0,1,2,3 is to determine the direction of the motion by determining whether the numbers increase or decrease (forward 0, 1, 2, 3, and backward 3, 2, 1, 0), and speed of the motion by determining how fast the numbers change. The program computes the speed as part of the main event loop. As of this writing the Mouse-Ball sensor is undergoing some design changes. 3 I2C and I2C-SC8 Devices The Lego RCX programmable brick is designed to have three input ports for sensors and three output ports for motors. The Bi-Pod robot design requires 8 position-controlled servo motors for both legs of the Bi-Pod; therefore third party I/O hardware extensions are necessary so we can still use the RCX programmable brick to control the Bi-Pod. The servo-motor is a position controlled motor that allows us to make precise positioning. The I2C-SC8 device is used to control the servo motors. 6

8 3.1 I2C Device The I2C [7] Device or IIC (Inter-Integrated Circuit) Device is a third party controller designed by Mindsensors.com for use with the RCX Programmable Brick, transferring data through the IR ports. I2C devices use 7 bit or 10 bit addressing [8] but ours uses 7 bit addressing, the most common choice. Therefore one I2C master device can have up to 128 I2C slave devices such as the servo controllers, different sensors, etc. Figure 7: The I2C device How it works The I2C Software Protocol for the Mindsensors.com I2C Device for the RCX robots has a specific transmission sequence that has to be followed in order to make it work. The data sequence that has to be sent to the I2C master device can be thought of as divided in two major parts, the header and the payload (Figure 8). Figure 8: I2C packet format (field entries for writing to I2C-SC8 with default address) Header 1. Starting Sequence (3 bytes): 0x55 0xFF 0xAA 2. Command read/write (1 byte): 0x57 (the letter W for Write) 3. Address of slave device(1 byte): 0xB0 (default, settable above 0xA0) 4. Starting Register (1 byte): point at which to begin writing payload data 5. Number of bytes to be written (1 byte): the byte length of payload Payload See the I2C-SC8 Device [9] (maximum 15 bytes long) 7

9 3.2 I2C-SC8 Device Figure 9: I2C-SC8, 8-channel servo controller by Mindsensors.com The I2C-SC8 Slave Device is a third party 8 port Servo Controller designed by Mindsensors.com for use with the RCX Programmable Brick, to control up to 8 servo motors. The I2C-SC8 device has 3 registers reserved for each motor, where the first register holds a speed parameter for the motor, and the other two registers are for the desired destination position where you want the motor to stop and stay. Table 1 shows the designated registers for each motor. 0x01 Servo 1 speed 0x0d Servo 5 speed 0x02 Servo 1 Position low byte 0x0e Servo 5 Position low byte 0x03 Servo 1 Position hi byte 0x0f Servo 5 Position hi byte 0x04 Servo 2 speed 0x10 Servo 6 speed 0x05 Servo 2 Position low byte 0x11 Servo 6 Position low byte 0x06 Servo 2 Position hi byte 0x12 Servo 6 Position hi byte 0x07 Servo 3 speed 0x13 Servo 7 speed 0x08 Servo 3 Position low byte 0x14 Servo 7 Position low byte 0x09 Servo 3 Position hi byte 0x15 Servo 7 Position hi byte 0x0a Servo 4 speed 0x16 Servo 8 speed 0x0b Servo 4 Position low byte 0x17 Servo 8 Position low byte 0x0c Servo 4 Position hi byte 0x18 Servo 8 Position hi byte Table 1: Registers for passing control parameters for individual servo motors Programmed control of the servos The I2C-SC8 Software Protocol is hard to understand for beginners who are unfamiliar with telecommunication protocols and it took time and assistance from others to grasp. At this point, the author switched away from using LeJOS for programming because the most error free online documentation provided by Mindsensors.com was in NQC (Not- Quite C), a C-like language for Lego RCX programmable bricks [3]. 8

10 Table 1 shows that each motor requires three sequential bytes for it to move to the desired location at a given speed. The first byte of this sequence is the speed of the motor from 1 to 255, with 0 meaning to move instantly to the desired position. The second and third bytes comprise a 16-bit destination position value that ranges from 500 to 2500 (the range of motion for a servo motor). Figure 10 shows one of the functions in NQC that moves the servo motor, which is connected to the first port of the I2C-SC8 device, to a desired position (parameter Servo_1) at a specified speed (parameter Speed). The Address parameter in Figure 10 needs to be the address of the I2C slave device, in this case the I2C-SC8 controller. The I2C-SC8 has a light diode on the board that indicates this address when powered up, by blinking the 2-hex digits in Morse code (such as B 0, for the default of 0xB0 unless changed by the user to some value greater than 0xA0). Figure 10: NQC function that controls the Servo-Motor 1 This function controls only one servo using a single packet transmission. Other functions that are identical to this for the other servos were also created (Servo_2, Servo_3, etc). One of the responsiveness problems, discussed later, was solved by other functions similar to this but that allowed control of multiple servos in a single packet transmission. 4 The Bi-Pod Robot This section will discuss the design and operation of the Bi-Pod including the problems encountered to this date. The goal of the author was to design a robot that would present some of the human-like balancing challenges for using a balance sensor. 4.1 Design and Operation The Bi-Pod robot contains four major parts: Mouse-Ball balancing sensor, I2C and I2C- SC8 controllers, servo motors, and two RCX PBs (programmable bricks). The Mouse- Ball sensor and the I2C and I2C-SC8 controllers have been discussed in the previous 9

11 sections therefore this section will focus on servo motors and the programming involved with the PB to control the movement of the robot. The Bi-Pod s first design had five servo motors for each leg configured into three main joints: hip, knee, and ankle. The hip and ankle each had two degrees of freedom. The servo motors used for this design are the Futaba S3003 series with 4 kg (1 kg = 2.2 lb) of torque per centimeter (1 inch = 2.54 cm) at 7.2 volts and 300mA. These servo motors were chosen due to the affordable price. Humanoid robots that are marketed today in the world use servo motors with torque power ranging from 10 to 15 kg per 1 cm. Using five servo motors for each leg made the robot very long and clumsy, due to the fact that the motors were not strong enough to hold the weight above As a result the knees were removed to reduce the length of the legs and improve stability (Figure 11). Figure 11: The Bi-pod robot. Servo motors have a little more than 160 of free motion. This degree of freedom is divided in 2000 different positions ranging from 500 to Using the Lego RCX PB, we send values between 500 and 2500 to the I2C-SC8 servo controller which is connected to the I2C device, to move the servo motor to a desired position. The Bi-Pod contains two PBs that control the robot. They are tightly coupled due to the fact that they share the Mouse-Ball balancing sensor. The motion detected on the horizontal axis is read by PB-1 (the leftmost PB in Figure 12a) and then transmitted to PB-2 (the rightmost PB in Figure 12a), which then reads the motion of the vertical axis using the Infrared (IR) signals and makes balancing decisions. PB-2 is connected to the I2C device and communication amongst these two devices is also through the IR ports. Using the IR ports for inter-communication between the PBs and also for communication between PB-2 and the I2C device requires a hardware solution to avoid cross talk and a software solution to synchronize communication between the PBs. These are described next with references to Figure

12 Figure 12: a) PB-1 (left) and PB-2 (right) units b) Plastic wall opening Each RCX PB has two built-in IR transmitters (circled in yellow in Figure 12a) and one IR receiver (circled in red in Figure 12a). Both PBs sit side-by-side, so the transmitter of one PB had to be bent in the direction of the other PB s receiver, and vice versa, in order for them to talk to each other. PB-2 is the unit that communicates with the I2C device, sitting in front of it, using its other IR transmitter. PB-1 s second transmitter is not used. To eliminate crosstalk between PB-1 s bent transmitter and the I2C device, a separating plastic wall was glued between the PBs with a small opening for the inter-communication link between them (Figure 12b). The software needs to synchronize communication between the PBs so that PB-1 stops talking when PB-2 needs to communicate with the I2C device. The main program runs on PB-2. At the start of this program, it sends a request for input packet to PB-1, and PB-1 starts sending a stream of packets with its light-sensor readings from the horizontal axis to PB-2. PB-2 will receive the IR data and calculate the position of the Mouse-Ball balance sensor. This will continue until there is a need for PB-2 to communicate to the I2C device to change the position of the servo motors, at which point PB-2 sends a stop sending command to PB-1. When PB-2 has finished sending commands to the I2C device it resumes communication with PB-1 by sending it a request for input. The I2C master device is connected to a single I2C-SC8 slave device that controls both legs. The I2C-SC8 servo controllers have eight possible ports for eight different servos. Each leg contains four servo motors and the motors of the right leg occupy port 1 through 4 on the I2C-SC8 servo controller, and the left leg occupies ports 5 though 8. The I2C- SC8 servo controller is placed between the legs to better fit the length of the servo cables (Figure 13a). 11

13 Figure 13: a) The I2C-SC8 device b) The Bi-Pod balancing on the left leg Figure 13b shows the robot (approximately 16 inches high) balancing on the left leg while the right leg is in the up position. To move a leg to a desired position requires control of multiple motors, four servo motors for one leg. Figure 14 presents the NQC function that alters the position of the left leg of this robot. After trying to send more data per packet, it was discovered that the NQC serial communication function was limited to a 16 byte buffer [10]. This limits us to controlling only three servo motors at a time (7-byte header sequence plus 3 bytes per servo). To overcome this limit, the author modified functions by mindsensors.com [7] to control more than three servo motors at a time. Figure 14 shows how this is done by calling the SendSerial function multiple times if necessary (in a while loop) in order to reuse the buffer to send a stream of bytes for a given packet. Wait times were necessary at certain points in the function to ensure that the data was fully delivered. The Left_Balance function takes a Speed parameter and assigns the same speed to all the servo motors. Figure 14: NQC source code to balance on the left leg 12

14 5 Conclusion The major problem area for this project was in understanding the I2C protocols. It took some time before finding the transmission sequence needed to move just one servo motor to a desired position with a desired speed. It was impossible to get the desired speed when operating one servo motor at a time with this protocol, so the next problem was in understanding how to operate multiple motors at the same time with a single packet transmission. More obstacles were encountered here too. The I2C-SC8 device is supposed to control up to eight servo motors at the same time, but because of the limitations of the protocol and the memory registers, we cannot move more than five. Another problem with the I2C device is the wait periods required after sending a buffer of data through the IR port, to make sure there is enough time to send the data from the RCX programmable brick to the I2C device. These wait periods are usually in milliseconds (1000 th of a second) which is a long time spent waiting for the data to be transferred for the RCX brick, a 16 MHz processor. These waiting periods also become a problem when trying to imitate a reflex action to re-adjust the balancing; therefore the robot needs to move very slowly, like an old person walking. The decision to use the I2C and I2C-SC8 devices was a poor choice and if given a chance to advance this robotics project, these devices would more than likely not be considered. Half-duplex IR media do not provide a fast communication environment. 5.1 Future Work The author pursued another idea for a balance sensor involving mercury (liquid metal), which is not easily available in the U.S and considered toxic. The challenge of materials, cost, and quality assurance caused him to abort this model, but he still believes it has merit as a more accurate balancing sensor and wishes to return to it using non-toxic materials. He named it the Liquid-Ball Balancing Sensor, essentially a hollow ball partially filled with liquid and with sensors distributed around its inner surface that could sense being submerged or not. Possible additions to this Bi-Pod would be the design and implementation of the arms since they could help increase the balance and stability of the robot. References [1] Wikipedia (2007). Pendulum. March 8, [2] Bagnall, B. Core Lego Mindstorms Programming. Prentice Hall, [3] Baum, D. Definitive Guide to Lego Mindstorms. Apress,

15 [4] Ferrari, G. et al. Programming Lego Mindstorms with Java. Syngress, [5] Bouncy Castle Hire Limited (2006), Gyroscope/Spaceball March 8, [6] Computer Hope.com (2007). How a mouse works. February 10, [7] mindsensors.com (2006). RCX to I2C interface module. January 15, PAGE_user_op=view_page&PAGE_id=33 [8] Robot Electronics. Using the I2C Bus. January 15, [9] mindsensors.com (2006). 8-channel Servo Controller (I2C-SC8). January 15, PAGE_user_op=view_page&PAGE_id=42 [10] Baum, D. Hansen, J. NQC Programmer's Guide Version 3.1 r5. 14