Archive for category: 3DoT Biped

BIREX WALKING CODE

By Brian Walton (Controls Engineer)
Approved by Paul Oo (Project Manager)
Approved by Railly Mateo (Systems Engineer)

Introduction to IDE:

The walking code for the μBiped project was coded in the Arduino IDE using the basic syntax used in C, C++, and the like. The use of a servo-driver dictated the need of having the Adafruit servo-driver library (available here: https://github.com/adafruit/Adafruit-PWM-Servo-Driver-Library) added to the already existing Arduino libraries for use. The addition of this library allowed the use of more servos than would have normally been available using the Arduino alone.

PWM:

In order to control individual servos the Arduino would use PWM signals to the servo-driver with each PWM associated with a different angle. These different PWM values were then set in an array in order to allow smooth movement of the legs, head, and tail that the servos were made to control. In order to get smoother movement, longer arrays were required to show more individualized movements.

Once the arrays started getting passed 100 individual elements the Arduino Processor no longer had enough memory to handle this. Therefor look-up tables had to be incorporated. Using look-up tables allowed the change from the Arduino being unable to handle the individual arrays (which at the time there were only 4 arrays), to being able to handle 12 individual arrays (only taking up 17% of the dynamic memory and 51% of program storage space). In order to use program memory, figures 1 & 2 show how all of the arrays had to be saved as “.h” files and saved in the same file as the Arduino program.

Array Variables:

Figures 3, 4, & 5 shows the variables used in order to add ease to coding later. The variables i,j,k, and l were added in order to scroll through the individual arrays. The variables forward1 and forward2 were defined in order to communicate with the Arxtera application as the combination of these 2 variables would allow 4 different individualized movements desired by the project: forward, left, right, and standing still. The variables left1, left2, right1, right2, head, and tail are used to take the arrays and translate it to the 6 individual servos and allows the program to be more iterative.

Long Array:

In the Arduino IDE the included files show up as long arrays in different tabs along the top of the IDE. The creation of these “.h” files were made in WordPad and is shown in Figure 7 & 8.

In order to learn how to use program memory to save space Professor Hill gave an example that will walk you through the process: http://web.csulb.edu/~hill/ee400d/Technical%20Training%20Series/(use the link that shows “Arduino_LookupTable.Zip”).

 

PCB DESIGN

By Michael Balagtas (Manufacturing Engineer)
Approved by Paul Oo (Project Manager)
Approved by Railly Mateo (Systems Engineer)

Introduction:

The Final PCB layout is the responsibility of the Manufacturing engineer. To maximize the grade acquired for the assignment, a combination of through hole and SMD packages were utilized in the design.

Obstacles:

The problem presents itself when there are too many components on a board. Some components will have plenty of connections, sometimes to the point where there is no choice but to block other channels. Naturally, the solution to this would be to rotate the device. However, doing so can block even more channels. Another option is to create a double sided junctions. However, the double sided wires starts blocking other bottom sided channels utilized by other components. The only other option would be to go around it. Unfortunately, the free version of EAGLE has a limit of 2 in. x 2 ½ in; therefore, we do not have the liberty of space to maneuver around the conflicted part.

The image above shows our finalized design for BiRex’s PCB. The red lines represent the copper tracing on top of the board, while the blue lines are underneath. An unpopular but effective method would be to have double sided SMD’s. By having an SMD on the bottom side, it is essentially mirrored by the axis that it is flipped on. This allows for some flexibility for routing.

There were some unforseen problems, however. When the board was mounted on the robot, all of the parts were nominal except for the ultrasonic pins, which are the 4 pins on the right of the picture. The pins were oriented in such a way that the ultrasonic was facing backwards; we needed to mirror the pins somehow. We used a daughter board to jury rig the pins into flipping to correct the mistake, which is the brownish board in the following picture.

Conclusion:

In summary, if the design needs a mirror, a double sided PCB can be utilized. However, it is important to note that it can limit the mounting capabilities. Furthermore, when using Eagle, having a reliable mouse aids in alleviating the amount of controls needed to design.

 

STRESS ANALYSIS USING SOLIDWORKS

By Michael Balagtas (Manufacturing Engineer)
Approved by Paul Oo (Project Manager)
Approved by Railly Mateo (Systems Engineer)

Introduction:

(This blog is written to accommodate stress test studies on strain heavy designs).

Previous Biped Robots had multiple joints connected by the servos. As such, it was easy to assume that, so long as the servo enclosure was thick and strong enough, the Biped could withstand the forces acted upon it during operation. However, for the 2015 BiRex design, the legs and joints are all connected via screws and nuts for articulation. Also, in order to reduce weight and size, some parts were thinned and holed, reducing their durability. This presents the team with a problem with the strain put on the joints and the parts as the BiRex moved.

Solidworks:

The parts had to be designed just enough to be easily manufactured and durable for walking. To accomplish this, the SimulationXpress feature on Solidworks was used to analyze the part for breaking points. The Simulation allows a user to determine which faces of the part will have a force applied into it (in the team’s case, the ankles) and which parts are stationary. It then allows the user to pick the specific type of material that the part is made out of, to determine the constants. By pressing run, the simulation starts calculating.

Results:

As a gauge, we considered the maximum force given by the robot as F = ma, which is the mass times the gravitational constant. In our case, 1.438 x 9.8 = 14.09N. The report indicated that the maximum force is above 65000N, which is way above our total forces.

The simulation then compiles a report in Microsoft Word that shows the simulation parameters and results. The most important is the von Mises Stress, which determines the force at which a material deforms. By being below this, the part is guaranteed to retain state after operation.

MOTION SENSOR TRADE-OFF STUDIES

By Railly Mateo (Manufacturing Engineer)
Approved by Paul Oo (Project Manager)
Approved by Railly Mateo (Systems Engineer)

Parameters	Gyroscope (ITG 3200)	Accelerometer (ADXL335)
Input Voltage	3.3	3.3
Acceleration	10,000G	10,000G
Operating Temp Range	-40 TO +105 CELSIUS	-55 TO +125 CELSIUS
Storage Temp Range	-40 TO +125 CELSIUS	-65 TO +150
Price	16 to 20 dollars	14 to 28 dollars
Dimensions	3.0×3.0×0.9mm	4 mm × 4 mm × 1.45 mm

Overview:

The accelerometer above is a compact device designed to measure non-gravitational acceleration. When the object it’s integrated into goes from a standstill to any velocity, the accelerometer is designed to respond to the vibrations associated with such movement.

A gyroscope above is a device that uses Earth’s gravity to help determine orientation. Its design consists of a freely-rotating disk called a rotor, mounted onto a spinning axis in the center of a larger and more stable. As the axis turns, the rotor remains stationary to indicate the central gravitational pull, and thus which way is down.

Trade-Offs:

The table above gives specification comparisons between a gyroscope (ITG-3200) and an accelerometer (ADXL335).

Conclusion:

For our robot we were planning on using a gyroscope to measure the level of an incline on which our robot maybe standing on. However, the gyroscope only measures the change in the surface and then it stabilize itself. For example, if the gyroscope goes from flat surface to an incline, it will detect the differences in ground and then it will set this ground as its new flat ground. In the other hand, if an accelerometer goes from flat to incline, it will display the change in surface and maintain the angle of inclination. Therefore, an accelerometer should be used instead of a gyroscope.

PROTOTPYE MILESTONES

By Railly Mateo (Systems Engineer)
Approved by Paul Oo (Project Manager)
Approved by Railly Mateo (Systems Engineer)

The video above shows the first step taken to understand the mechanics for how our Bipedal robot would walk. This model is considered our 1st Generation (1.0) of BiRex. It is a simply demonstration of a 5-axis leg using MG90S servos to rotate 2 axis, which then cause the rest of the leg to be displaced based on the angles of rotation. The commands used for this demonstration can be found in the Arxterra Application blog post.

This second video shows how we attempted to understand the coding for making our Bipedal robot walk. This model is considered our 2nd Generation (2.0) of BiRex. Although it has integrated 2 5-axis legs onto a body (wooden plank), this model lacked the feet needed to test stability.

This third video shows how we attempted to understand the motion for making our Bipedal robot walk. This model is considered our further developed 2nd Generation (2.5) of BiRex. As you can see, it has difficulty walking. This lack of balance comes from the fact that our legs cannot support overall stability alone, thus verifying the need to add the head and tail.

The image above shows the inclusion of servos for head and tail. However, after showing the progress of our prototype to Professor Hill, he recognized the need to change the design of the leg. This model was unable to lift its leg up, but rather slid to go forward. Because of this detail, we were able to implement a more realistic prototype and find valuable feasibility information.

The image above shows the finalized design before moving into producing our last model. Although the plastic molding made the structure too heavy to stay standing, the legs’ rotations resembled human-like walking motion.

Conclusion:
After changing the Mission Profile & Project Objective, we were able to focus our time into learning from trials and errors. This, along with a progressive design innovation, gave us enough data to create proper verification and validation tests.