Archive for the ‘Electrical Aspect’ Category

Saber Board PCB Design

March 28, 2011 Leave a comment

In an effort to properly interface with the National Instruments SBRIO both mechanically and through software, the team developed a PCB.  The PCB was designed mainly as a breakout board, but also incorporated operational amplifiers for sensor inputs.  The PCB design was developed in the EAGLE Layout Editor utilizing two of the 50pin connectors on the SBRIO.  One of these connectors was primary used for Analog Inputs and the other was used for Digital I/O.  In addition the board was designed to have a 5v input rail in order to provide the voltage necessary to run the many sensors attached to it.  The final schematic for the Saber Board can be seen below.

With the schematic complete, it was necessary to create the footprints for the connectors which would be used.  We used Digikey PN # 67-1062-ND to interface with the 50 pos cable from the SBRIO and PNs #455-2248-ND/455-2219-ND to have secure three pin molex style connectors.  With these connectors the board layout was created and the programs auto routing feature was taken advantage of.  While the auto routing feature was not perfect it did save some time.   Two of the most important things that were done to the auto routing were to eliminate all sharp angles and to create both a ground and power plane on the top and bottom of board respectively.   These planes also served to help reduce both high and low frequency noise on the system.  The final board layout that was compiled can be seen below, the red lines represent traces that were placed on the top and the blue lines are the traces on the bottom.

We printed our boards with 4PCB and couldn’t have been happier with the return time.  We had our boards in head less than a week later.  The boards were then assembled and tested as seen below.

While we were working on this PCB externally to the SBRIO, there was also a development plan for the LabView code which would interface with the PCB.  The VI for this interface was setup to mimic the physical appearance of the PCB with the same naming scheme to ease the overall interface between the PCB and SBRIO.  This will allow future calls to the I/O pins to be intuitive and reduce the amount of errors.  The VI can be seen below and as you can see has the same row/ column layout as the physical PCB.


Computing Gait’s Revisited

March 22, 2011 Leave a comment

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

March 20, 2011 6 comments

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.

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; 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 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

September 29, 2010 Leave a comment

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.