Dragoon
4-leg spider robot
Early 2020
Inspired by Starcraft combat unit Dragoon and Assault type Thomas by Y NAKAJIMA
Introduction
Wheeled vehicles are easy to work them because their control is relatively simple - they have only two degrees of freedom. However, wheeled vehicles are not as adaptable as legged robots when they travel in various road conditions. Upon graduation, I decided to do something fancier as a project. And after seeing the Y NAKAJIMA's Assault type Thomas spider robot on Youtube, I was seriously impressed by it and decided to make a similar but different 4-leg spider robot.
I started working on the design section in January 2020. After the semester started, I decided to use it as the class project for ME 102B. I formed a team with three other people: Graham, Linus, and Jeremy. Together, we decided to add a turret to it and make it like the dragoon in Starcraft. As for the initial teamwork distribution, I and Graham will be working on the lower half of the spider which is the base, where I will be working on the entire motion mechanism, GUI design, control, and Graham will be cooperating with me on the control; Linus and Jeremy will be working on the upper half which is the turret.
Base Design
Motor selection
My intention is to make the robot as simple as possible. The size of the motors should match the size of the robot, which I intend to be less than 25cm in length, so the best candidate for the motor will be the MG90S servo. As the structural parts can be made of carefully designed plywood which has a very low mass, I imagine that the motors will not have a problem supporting the weight of the robot.
Arm design
Each arm of the robot should have three degrees of freedom to allow the foot to move in 3D. I choose the same arrangement of motors as Dragoon and the Thomas spider - one vertical motor at the joint with the central body, and two horizontal motors at the two arms on the outside. The arms are made of plywood plates and their shapes are designed in a way that minimizes the complexity.
Overall design
The four arms are circularly patterned around the central body. To reduce the complexity, the two structural plates of the central body are in direct joint with the servos of the four arms. The base design is finished before the Spring 2020 semester.
Motion Control Strategy
The real fun part
Mechanisms are very fun to work with for mechanical engineers like me. However, a robot without control is like a human without a soul. Control is the core and the real fun part of this robot. Coordinating the 12 actuators to perform a series of motions is the main challenge.
The robot can be controlled in two modes: discrete mode, and continuous mode. The discrete mode is the simplest of all, in which one or a few servos are commanded to go somewhere at a time, and the system waits for a pre-programmed fixed time to allow the servos to go to their desired positions. This is very simple to implement - you just need to write a function with “PWM write” and “delay” commands. However, this strategy is very inefficient and the resulting motion will not be smooth at all. While I will write a control in this mode in the very first place to test if the system works, my goal is definitely a better control strategy, and that is the continuous mode.
Continuous mode means that all servos are commanded simultaneously. This way, the resulting motion will be so much smoother since there is no pause for any servo. There are two ways to implement this. The first is to compute the desired position for each servo in real-time based on the intended motion and command the servos to go there. If the control is written well, the robot can do hybrid motions, e.g. translating and rotating at the same time. However, this would require a lot of computation which I do not think Arduino can handle.
The other way to implement continuous mode is by pre-recording. We first decide on our intended motion, then, we can compute the desired position for each servo using MATLAB and save them to a matrix. Finally, we let the Arduino command the servos to go through the positions in the matrix. Since I am using analog servos that have a very low frequency of 50Hz, the resolution of the matrix will not be too high to endanger the memory. This method is what I will use to implement the control.
Showcase for basic motion
This is the basic motion control that I wrote. The servos follow a series of "PWM write" and "delay" commands to move the robot.
Change of Situation
The coronavirus is developing fast, and that causes our school to close. The ME 102B class also changes its policy such that prototyping is no longer necessary. However, this should not stop me from working on this project. Therefore, I decided to take the robot home and work on it on my own during the spring break. My initial goal is to finish the continuous mode motion for turning and translating and develop an Android app that controls the robot.
Kinematics Analysis Setup
The robot has 12 degrees of freedom which makes control a lot harder than most traditional machines. As a result, we have to do a careful kinematics analysis on it. The first step is to convert the robot into a simplified model.
General model
We define the projection of the center of the central body to the ground as our origin O and define an inertial frame fixed coordinate system on it. We mark the hinge of each leg with the central body with an index. We define the radial extension of a leg when the central body is not rotating in the yaw and pitch axes as r, and the angle it makes with E_x as theta. Note that O and A, B, C, D are not on the same plane.
Central body rotation
We define a body fixed coordinate system that rotates with the central body. We define the rotation in the yaw-axis as theta_c. The central body can also rotate in the pitch and roll axes. However, At this point we do not consider them since they will make the our definition for r invalid. Nevertheless, we will change the model slightly when we reach the yaw-pitch control section.
Leg model
Now we go to leg A for example. We define the arms starting from the inside as arm 0, 1, 2. We can define a leg-fixed coordinate system that tracks the yaw rotation with respect to the central body of arm 0. Then arm 1 and arm 2 rotate in the e_theta direction. We define the three arms angles as theta_0, theta_1, and theta_2.
Final overview
Now our model is complete, we can design our motion case by case.
Rotational motion
Turning start
The turning motion starts with the feet of two legs lifting off. In the case illustrated in the picture, legs B and D lift off, and the feet of legs A and C stay in contact with the ground. Legs A and C then rotate, and that causes the central body to rotate too. However, the radial dimension of each of the legs A and C changes such that they do not slide. The legs B and D are maintained parallel to BD.
Turning land
Once legs B and D have reached their desired positions, they land their feet. In this instance, the angles of legs A and C have changed, while the angles of legs B and D have not.
Turning other pair
Now, we lift off legs A and C and turn legs B and D. The feet of legs B and D should stay in contact with the ground, and legs A and C should rotate in the air to return parallel to AC. Once legs A and C have reached the desired positions, they land.
Other pair land
As you can see, this is basically the mirrored image of graph 2, so we just repeat the two mirrored processes and the robot will be turning continuously. If we can minimize the landing time, ideally, the angular speed of our robot will be constant.
Kinematics analysis
The radial dimension, r, of a leg must change to ensure that it stays on the dashed circle so that the foot does not slide. To achieve this, we first derive r as a function of turning angle theta. Note that OA is the horizontal projection length. Then, we know that r is the radial extension of the three leg arms, so we can link that to the arm angles. We fix z since the height of the robot should not change, then we can solve for the three arm angles from theta.
MATLAB simulation
When a leg is in the air, we do not care about the arm angles as long as the leg can reach its target on time. For the leg that is in contact with the ground, we set theta_c as our input and compute the three arm angles. We use linear spacing in our theta_c values to make the robot turn at a constant angular speed. Then we can map the angles to PWM signal and export the PWM array to Arduino.
Arduino code
The traditional keys on the keyboard for turning are Q and E, therefore, I use them as the command that triggers the Arduino. The turn functions basically follow the same logic described above. They take two inputs, one for the direction, and one for which side to not lift and rotate.
_edited.jpg)
Continuous turning motion, wireless control
Progress as of March 19, 2020
Translational motion
Moving start
When starting to move, our robot has to morph from the neutral configuration on the left into the moving configuration on the right. Legs A and C are parallel, and legs B and D are parallel. The distance between the feet of legs A and B, and that between the feet of legs C and D should not change.
Moving step 1
In this step, the feet of legs A, B, D stay in contact with the ground, and leg C lifts off and goes to the front and land. The length of each leg that is in contact with the ground changes with the change in leg angle in order to not slide on the ground. At the end of this step, the center of the central body is displaced by delta_y.
Moving step 2
In this step, the feet of legs A, B, C stay in contact with the ground, and leg D lifts off and goes to the front and land. At the end of this step, the center of the central body is displaced by delta_y from the last step, and 2delta_y from origin. We can see that the robot's configuration is the mirror image of the starting configuration. Therefore, we just need to mirror the process for the next 2 steps, and run the total 4 steps repetitively.
Kinematics analysis
In this case, the constraint for the feet to stay on the ground is a constant x. As the central body moves forward by delta_y, the feet that stay in contact with the ground move backward by the same amount. As a result, we can use that as our input and solve for the arm angles. Since servos use position control, we use linear spacing in our delta_y values to make the robot move at a constant speed. We then use MATLAB to get the arm angle arrays.
MATLAB simulation
Same as the turning motion, when a leg is in the air, we do not care about the arm angles. For the leg that is in contact with the ground, our input is y. We also use linear spacing in our y-array since we want the robot to move at a constant linear speed. We solve for the three angles using the math equations. Then we can map the angles to PWM signal and export the PWM array to Arduino.
Control
The traditional keys on the keyboard for moving are WASD which is also what I implemented in my code. In the linear motion mode, there is a much larger speed difference between on-the-ground legs and in-the-air legs. As a result, I have to tune a lot to figure out the best speed for the servos to not jerk as they tend to shake a lot when sending position commands that do not match their top speed.
Continuous linear motion, wireless control
Progress as of March 21, 2020
Yaw-pitch and height control
Intention
A normal turret has two degrees of freedom: rotation in yaw and rotation in pitch. Since the robot has 12 degrees of freedom already, it will be ideal to use the existing motors to do the control. Since we have two inputs in this case, our recording for each motor will be a 2D array which is a matrix. The height control is an independent and supplemental feature.
Image by JackBlack from 3D Warehouse
Central constraint
The central constraint for both yaw-pitch control and height control is that 4 feet stay in contact on the ground. The height control is very simple, we just fix r and change z and get the desired angle arrays. However, the yaw-pitch control is fairly complicated, and we need to do some math.
The complete model
Our governing equation in this case is that the OE, OA, AE vectors form a closed triangle. Since our feet always stay on the ground, we know that O and E are on the same plane and stationary.
Kinematics analysis
We can express the three vectors in vector form. We note that the vector for AE is in a different coordinate system from the other two. As a result, we must perform a coordinate transformation to map it to the same coordinate system as the other two so that we can solve the equations.
Coordinate transformation
Our goal is to convert the leg-fixed polar coordinate to the inertia-frame-fixed coordinate. We begin with the yaw-rotation coordinate transform. This rotates with respect to the E_z direction.
Coordinate transformation
The next rotation is the pitch rotation. This rotates in the e_1 direction. After the rotation, the coordinate system changes to the body-fixed coordinate system previously defined.
Coordinate transformation
Finally, our last rotation is the leg rotation on the hinge. This rotates in the e_z direction. Now we have arrived at the same coordinate used to express the vector AE, we can then convert everything back to the fixed coordinate system.
Kinematics analysis
At last, we have express all the vectors in the same coordinate system. We have 2 inputs, 3 equations, and 3 unknowns. Therefore, we can use fsolve in MATLAB to compute the arm angle matrix.
MATLAB simulation
We have two inputs in this case: theta_c and phi_c. We solve for the three angles using the math equations. This time, our solution is a matrix since our input is 2D We map the angles to PWM signal and export the PWM matrix to Arduino.
Control
Our control for yaw-pitch is different. We use the joystick signal to determine the indices for the signal matrices. For the height control, the same strategy is applied but we have an array instead of a matrix as we only have 1 input. We do not follow any sequence of motion so our control is real-time.
_edited.jpg)
Yaw-pitch control
Progress as of March 23, 2020
Arduino Control
I used Teensy 3.2 as the micro-controller. The microcontroller communicates with the Bluetooth module, which receives signals from the phone. The control inputs are the keys that are used in most PC games. However, for yaw-pitch and height control, the joystick position is also used. Therefore, the phone will send mostly keyboard key strings through the serial communication channel as the commands, and sometimes add to them the joystick position values.
Thanks to Graham Johnson for cooperating with me on the code.
Graphical User Interface
Android App developed using the MIT App Inventor
I tried to use the Android Studio as first to develop the android app that controls the robot. However, I am too inexperienced in Android programming that I can't get it done in a short time. Then I saw a video by Electronoobs on Youtube that discusses developing an Android app using the MIT App Inventor to control the Arduino. I immediately switched as I found the App Inventor to be a lot more friendly to use.
My GUI takes inspiration from sci-fi spaceship control panels. On the left side, we have the moving control joystick and turning control buttons. On the right side, we have a yaw-pitch control joystick and a height control slider. The shift button is to accelerate the moving speed just like what you do in FPS games. The top panel allows you to select the control type. The network icon in the bottom middle is the Bluetooth connection list. Overall, the design is similar to most Mobile games.
"Final" Showcase
Progress as of March 26, 2020
GUI (developed using MIT App Inventor)-controlled motion. Able to move in x, y, and z and rotate in yaw and pitch. In total 5 degrees of freedom.