Archive
The First Steps of Sabertooth and MQP awards!
We are beyond excited to share with you Sabertooth’s first steps:
The footage here is merely proof that we have succeeded in having full control of our system. As we calibrate it further, we will be giving Sabertooth much more control. What we are currently doing is similar to training a baby how to walk, stay tuned for more!
We would also like to share that the team has won the following awards:
- Provost award in the Robotics Engineering department
- 3rd place in the Mechanical Engineering department
- 1st place in the Mechanical Engineering department with a Robotics concentration
- SME Manufacturing award
Sabertooth is born
Little beautiful 275 pound, 5 ounce baby Sabertooth finally makes her debut.
Welcome to the team!
The team has acquired some new help for D term!
We welcome Brennan Ashton and Paul Heslinga to team Sabertooth!
-
- Brennan Ashton
-
- Paul Heslinga
Paul has been a huge help with assembling the robot , welding the frame together , and electrical wiring. He’ll also be helping out with some of the software architecture.
Brennan is going to be helping out with implementing the control and communication protocols of the robot. Both Paul and Brennan will be a huge help as this project comes to the end of the school year. Welcome!
Computing Gait’s Revisited
The latest and final solution we have implemented for the calculation of Gait generation involves the following picture:
These graphs depict duty cycles of various gaits. The black represents the percent of the foot touching the ground, and the rest represents time in the air. The way I chose to go about creating a solution was to visualize an arc being made. An arc in 3D space is represented by a height, width, and length. These are the parameters my simulation takes in (as well a speed). Previously I created functions to express the motion of a gait within an animal, yet found it to be troublesome for precise foot placement.
The following explains the gait algorithm implemented in our robot. We start by creating a gait loop which represents going through a gait from 0% to (final cycle+duty cycle)%. The duty cycle is represented by the max percentage of time the foot is spent off the ground and the final cycle is the percentage at which the last foot in the series leaves the ground. So as an example, in the bound gait the duty cycle is approximately 35% and the final cycle is approximately 70%- hence the loop will be from 0% to 105%. Lastly we just need to create an offset for each leg, the the first contact with the ground for the foot. Again, looking at the bound gait- LF and RF offset’s will be 0% and RH and LH will be 38%.
As you iterate through the loop, there will be a time when the leg is off the ground, less than the offset and greater than the offset+duty cycle, 0% to 38% and 70% to 105%, where the leg will be in the air. 38% to 70% it will be on the ground. To calculate the desired x, y, z of the foot going through the gait I do something similar to following:
//Leg 1 Motion Planning
/*
i is the iterator or current percentage in the cycle
i0 is the "phaser", or the "angle" within the arc
Fl, Forward locomotion is a boolean that is 1 when the robot should be moving forward, 0 when it should be stopped. Vl is vertical, Hl is height- same concept.
Desiredx is initialized to where the foot is initially in your system along the X axis, Desiredy is along the Y axis, and Desiredz is along the Z axis.
length, width, and height are how much range of motion you want.
maxi is the offset+duty (total cycle time)
*/
if ((i > offset) && (i <= (offset + duty))) { i0 = (i - offset) * (360 / duty); //Where in the phase you are as you iterate through the gate (0 -> 360 degrees)
Desiredx = Desiredx + Fl * width * (1 / duty); // Calculates the desired x
Desiredy = Desiredy + Vl * length * (1 / duty));
Desiredz = Desiredz - ( Hl * sin(i0 * PI / 180) * 2 / duty * height;
}
As I iterate through the gait, I then solve for the inverse kinematics of the system, which give me angles necessary for each ‘link’ to get to to reach each desired x,y, and z. The hip is more complicated because we are using a linear actuator, so some math is involved to calculate what position the motor must achieve to move the actuator out far enough to tilt the entire leg the necessary amount (trig required!). You can see results of this down below in the gallery.
After creating the MATLAB simulation I showed prior that allowed me to calculate positions, velocities, accelerations, and torques of Sabertooth, I noticed that the processing was beginning to take a heavy toll on the CPU. The graphical visualization of how the system moves was a phenomenal help for testing. It allowed us to change variables concerning the stride length, width, and height (how much the end effector was allowed to move per gait cycle). It allowed us to actually walk around while changing the speed and orientation of the robot.
However, the lag in this simulation was beyond anticipated and unfortunately rendered the simulation window to not be used as the “controller” for the robot that would represent our robot’s orientation as it walked in 3D.
As a replacement we have created a C++ program which will work alongside the ROS package(used for path planning, Lidar, IMU, and communication with the NI sbRIO) that we will be enabling on the ASUS eeePC. Matlab will still be an important part of logging and understand the enormous amount of data our robot will output because it will allow us to plot the data.
Currently the C++ Program is used for gait generation, and inverse kinematics – which will enable us to (almost) instantaneously calculate gaits and solve what position each motor must be at by the microsecond- allowing for smooth paths for our legs. The C++ also logs all the calculations, and a MATLAB script is used to interpret the 1000s of numbers logged.
To understand the following data, we must understand that Link 1(attached to the body) moves the entire leg laterally, Link 2 moves the leg(thigh and ankle) tangentially to the body, and Link 3 moves the ankle tangentially to the body.
The following is data plotted for the C++ logging files on different gaits our robot can test(hopefully):
Maxon Motors and Labview sbRIO
We have completed getting control of the hip of Sabertooth! This will allow us to tilt our legs laterally by ~10 degrees in each direction using a linear actuator.
The following components were used for the task:
- National Instrument’s sbRIO – 9632xt, Embedded control with FPGA
- National Instrument’s 9853, 2 Port High Speed CAN Bus with 1 Mbps transfer speeds
- 4x Maxon EC Max 40, Brushless 70watt motors with incremental encoders
- 4x EPOS2 70/10, 25 A motor controllers
Utilizing the instrumentation mentioned above- we have managed to obtain full control of our linear actuators we have designed. The end result allows us to send packets of information to the sbRIO with desired positions. The real time processor will calculate the PID loops and pass information to the FPGA which will package it up into frames and send it to the CAN bus and onward to the controllers or ‘nodes’. These packets will arrive at a desired node in the network and will execute the frame.
The Labview 10 provided a great example in the Robotics toolkit with drivers of how to obtain communication with the EPOS2 controller. However there was a significant timeout error that we ran into, error decimal 7801, that we would like to share and explain in case someone runs into this issue in the future.
Read CAN.vi<ERR>
CAN read timed out attempting to read COB ID x581. The data you are trying to
read from the CAN bus timed out before it was recieved. Make sure your device is communicating properly.
Though originally when we contacted the NI support team for help (Thanks again Greg Jannaman!), we thought the problem was revolved around the program and the timeout in the Read CAN.vi; NI suggested increasing the timeout loop and that gave us a successful result which allowed us to establish communication with the controllers. However, after raising another issue we were having with the EPOS2 controllers starting in the Error/Disabled state (Red LED) we realized the error was in the CAN communication baudrate. The error the EPOS2 would give us upon starting was always “CAN in Error Passive Mode”, to fix this error we utilized the EPOS Studio and accessed the Controller’s Object Dictionary to change the system parameter “Can Bitrate” from decimal value 0, 1Mbps, to 9, Automatically detect bitrate. This resolved the error from appearing each time the network was started.
We changed the Motor Position Control.vi to utilize 4 motors. The next step is to implement limit switches with the linear actuators which will allow us to home our motors on each initialization. We will also add force and current sensors into each leg to give us more information about the state of our system as well.
We’re at an exciting point in our project and we are overwhelmingly excited to be finally assembling the entire robot within the next two weeks! More news and pictures coming VERY SOON!
Dynamics of the Robot
Maxon is offering to supply motors to us, and to work with us in figuring out which motors we specifically need. However we need to calculate torque required for the motors for two reasons. One is to be able to physically support the robot statically. Two is to be able to be able to move the leg with the weight throughout the leg.
To calculate this we need to do Lagrange equations. We used Maple 12 to solve them.
We began by calculating the D-H parameters for a leg on the robot. Once these are established we moved onto transformation matrices for the joints on the robot. From here we would understand how to transform two coordinates (start of the leg, end of the leg) by inputting the D-H parameters we obtained. We also established center of gravity matrices.
When calculating we excluded the foot’s revolution because it is not controlled by a motor, and is only controlled by springs and it would only complicate things unnecessarily.
To find the Lagrangian we solved for the Kinetic and Potential energies of each mass(1st link, 2nd link, 3rd link(which includes the foot)). L=Ktotal-Ptotal, where K is 1/2 * m * v^2 and P is 1/2 * m * g * h
From there, we began taking the derivate of L with respect to theta[link](t) , then taking the derivative of that with respect to t to get an expression.
Then we took the derivative of L with respect to theta[link](t) to get another expression.
Subtracting these two expressions results in the solution of the Lagrangian.
Matlab Simulation
I have been researching dog gaits and gathering data to try to mathematically describe them.
There is a lot of information out there on gaits and motion, yet none of the papers I have read actually described them mathematically. Currently, I have been able to describe two gaits mathematically: Running and Walking. Running is described as a gait where at a point in time all feet are off the ground, where in contrast walking is described as a gait where one foot is always in contact with the ground.
To describe the running gait, I found 8 drawn frames of a dog running, I estimate the angles in relation to each other and compiled a list. In the list I show angles of a front and back leg, with 4 limbs. The rows of the Front Right Leg describe different bones: humerus, radius, metatarsal, phalnax. The rows of the Back Right Leg describe different bones: femur, tibia, metatarsal, phalnax. The columns describe the frames- 1 to 8.
Functions:
Front Right Leg:
Front Left Leg
Back Right Leg
Back Left Leg
R² = 0.5147
Sabertooth Robotics MQP Blog 