Project Logs

Collapse

• Improving the leg mechanism and new PCB board.

  Miguel Ayuso Parrilla • 11/01/2022 at 02:17 • 0 comments

  It's been a while since I don't update the project but it doesn't mean I've stopped working on the robot ;)

  About the code, there is still a very primivite version of the model at Github. I've been also improving it but still some cleaning up of the code needed as I want to show it clear to understand. Hope on next months it cound be done!

  You can check further updates on Instagram
  

  ---

  Desinging a PCB board

  I want to share PCB I made to interface all conections. Making wiring by hand is always tedious and it can be cosidered like an art.

  But now is very easy to design and manufacture your own PCBs for a very small budget.

  The board is very simple and make the wiring job very straight forward. The carateristics are:

  • Teensy 4.1 interface. It is very fast, which can handle even LCD and achieve high frequency.

  • I2C bus for 9-DOF Absolute Orientation IMU, bno055 in my case.
  • Serial tx/rx and Vin to power Teensy.
  • 13 servo connections divided in 4 different power supply.
  • 13 analog input, in other to read each servo's potentiometer.
  • Voltage divider to read battery voltage.
  • 3V3 output.
  • Push button.

  ATTENTION!: If powering Teensy through 5V pin power supply, don't connect USB supply. As both voltage at the same time can damage microcontroller.

  Manufacture it is very easy now, Thanks to PCBway we get high quality PCB plus very good service, solving any manufacturing doubt very fast. It was very easy to order the boards!
  

  You can get PCB files here.

  
  

  ---

  ________________________________________________________________________________
  

  
  

  Improving the leg mechanism.
  

  
  

  Along this 3 years I have been trying several leg mechanism.
  

  Finally I decided to do a simple design with tibial motor placed on the femur joint.

  But this design still had several problems, like it wasn't very robust and the most importat is that having the motor (with big mass) that far from the rotating axis, caused in fast movements, unwanted dynamics to the robot body, making controlability worse.

  New version have both motors of femur/tibial limb at coxa frame, this ends with a very simple setup and at the same time, the heaviest masses of the mechanism are centered to the rotating axis of coxa limb, so even though the leg do fast movements, inertias won't be strong enough to affect the hole robot mass, achieving more agility.

  Inverse Kinematics of the mechanism

  After building it I notice that this mechanism was very special for another reason, at the domain the leg normally moves, it acts as a diferential mecanism, this means that torque is almost all the time shared between both motor of the longer limbs. That was an improvent since with the old mechanism tibial motor had to hold most of the weight and it was more forced than the one for femur.

  To visualize this, for the same movement, we can see how tibial motor must travel more arc of angel that the one on the new version.

  In order to solve this mechanism, just some trigonometry is needed. Combining both cosine and sine laws, we can obtain desired angle (the one between femur and tibia) with respect to the angle the motor must achieve.

  Observing these equations, with can notice that this angle (the one between femur and tibia) depends on both servos angles, which means both motors are contributing to the movement of the tibia.

  ---

  Calibration of servos

  Another useful thing to do if we want to control servo precisely is to print a calibration tool for our set up. As shown in the image below, in order to know where real angles are located, angle protactor is placer just in the origin of the rotating joint, and choosing 2 know angles we can match PWM signal to the real angles we want to manipulate simply doing a lineal relation between angles and PWM pulse length.

  Then a simple program in the serial console can be wrtten to let the user move the motor to the desired angle. This way the calibration process is only about placing motor at certain position...

  Read more »

• New leg design.

  Miguel Ayuso Parrilla • 07/29/2022 at 12:20 • 4 comments

  This log is just to let all know that I'm still working on the robot. It's been quite a long time without any update (Studiying physics require must of my time this past years) but I've been doing some important progress on leg design and simulation.

  From now I'll be updating and producing more content about the robot. Stay tuned!
  

  Until then, to ilustrate what is coming, here a render of the new leg.
  

  Testings on this design have shown a quite remarkable improvement on performance.
  

• Project bibliography and interesting papers.

  Miguel Ayuso Parrilla • 10/02/2020 at 13:42 • 0 comments

  Here i'm going to show all the bibliography related with the project and some other reading that has inspired me.

  Software documentation:

  • Pybullet full documentation and guide.

  ---

  More mathematical Articles:

  • Inverse Kinematic Analysis Of A Quadruped Robot.

  • Leg Trajectory Planning for Quadruped Robots with High-Speed Trot Gait.

  
  

  • Dynamic Locomotion in the MIT cheetah 3 Through Convex Model-Predictive Control.

  
  

  • Foot Design for a Hexapod Walking Robot.

• Small community.

  Miguel Ayuso Parrilla • 09/28/2020 at 15:32 • 3 comments

  This log is just to show the repercussion of the project and say thanks for the support from all of you that are reading this project.

  This is awesome to see that the hard work you made can be very useful for others. Even to the point of creating a new platform with a small community that is growing every day.
  

  This project has let me see the values of the OPEN SOURCE community, how easy is nowadays to develop a new platform, each contributor from very different places in the word but with one commun interest that is learn things in order to make our lives more interesting.

  Here are some of Makers that supported the project since the first day and they already have a small Chop at their homes:
  

  Thanks to @OilSpigot 

  (min 4:00 to see his robot in action)
  

  Thanks to @Creasento:
  

  
  

  
  

• Bill of materials and price of the robot.

  Miguel Ayuso Parrilla • 09/19/2020 at 12:33 • 0 comments

  To complete the Component Section, in this log i want to show the complete bill of materials, with the price for one unit of the robot, i have to say i'm surprised how cheap it is to build just one robot.
  

  In my case, this development has been more expensive as i have made 3 different prototypes with its resvective components, so more or less i have spent two times the price of one unit.

  Almost all componet were bought from the typical chenese online wareshops.
  

  Once you have all the components, the building procress is not very hard if you have experience with 3D printed prototyping.
  

  Go to Instruction Section
  

• PyBullet Simulation example

  Miguel Ayuso Parrilla • 09/15/2020 at 13:06 • 0 comments

  This log i'm going to talk about the simulation used for the robot development, this was mostly used for debugging the maths inside the the different models.

  The code of the simulation is no longer implemented in the Raspberry code, as it can't support GUI mode and i'm not taking data from PyBullet environment. The code i am referring to is at the V1_PCsimulation branch of the robot GitHub repository.

  
  This code can be ran with the robot just plugging the arduino to the PC via USB and run the robot_walking.py file, all requirements at README.md

  But if you don't have the robot built, you can run just the simulation a play along with the robot inside the PyBullet environment. Also feel free to modify it and improve it.

  You just need PyBullet and Numpy on Python 3, then download the V1_PCsimulation branch and run walking_simulation_example.py.

  More info of how the simulation works shown in the next video:
  

  ---

  Now, i'm going to breightly explain the main code of the simulation, here is shown:

  """
  Created on Sun Mar 15 19:51:40 2020
  @author: linux-asd
  """
  
  import pybullet as p
  import numpy as np
  import time
  import pybullet_data
  from pybullet_debuger import pybulletDebug  
  from kinematic_model import robotKinematics
  from gaitPlanner import trotGait
  
  """Connect to rhe physics client, you can choose GUI or DIRECT mode"""
  physicsClient = p.connect(p.GUI)#or p.DIRECT for non-graphical version
  p.setAdditionalSearchPath(pybullet_data.getDataPath()) #optionally
  """set Gravity"""
  p.setGravity(0,0,-9.8)
  
  """import the robot's URDF file, if it is fixed no ground plane is needed""" 
  cubeStartPos = [0,0,0.2]
  FixedBase = False #if fixed no plane is imported
  if (FixedBase == False):
      p.loadURDF("plane.urdf")
  boxId = p.loadURDF("4leggedRobot.urdf",cubeStartPos, useFixedBase=FixedBase)
  
  jointIds = []
  paramIds = [] 
  time.sleep(0.5)
  """get info along all the joints for debugging if needed"""
  for j in range(p.getNumJoints(boxId)):
  #    p.changeDynamics(boxId, j, linearDamping=0, angularDamping=0)
      info = p.getJointInfo(boxId, j)
      print(info)
      jointName = info[1]
      jointType = info[2]
      jointIds.append(j)
      
  footFR_index = 3
  footFL_index = 7
  footBR_index = 11
  footBL_index = 15   
  
  """init the classes used"""
  pybulletDebug = pybulletDebug()
  robotKinematics = robotKinematics()
  trot = trotGait() 
  
  #robot properties
  """initial foot position"""
  #foot separation (Ydist = 0.16 -> tetta=0) and distance to floor
  Xdist = 0.20
  Ydist = 0.15
  height = 0.15
  """This matrix will define where the feet are going to be at its standing position
  with respect the center of the robot"""
  #body frame to foot frame vector
  bodytoFeet0 = np.matrix([[ Xdist/2 , -Ydist/2 , -height],
                           [ Xdist/2 ,  Ydist/2 , -height],
                           [-Xdist/2 , -Ydist/2 , -height],
                           [-Xdist/2 ,  Ydist/2 , -height]])
  """Gait definition parameters, here you can set different period of step and
  the offset between every foot's loop, defining different gaits"""
  T = 0.5 #period of time (in seconds) of every step
  offset = np.array([0.5 , 0. , 0. , 0.5]) #defines the offset between each foot step in this order (FR,FL,BR,BL)
  
  """start a real time simulation, so no simulation steps are needed"""
  p.setRealTimeSimulation(1)
      
  while(True):
      lastTime = time.time()
  """show sliders in the GUI"""
      pos , orn , L , angle , Lrot , T = pybulletDebug.cam_and_robotstates(boxId)  
      #calculates the feet coord for gait, defining length of the step and direction (0º -> forward; 180º -> backward)
      bodytoFeet = trot.loop(L , angle , Lrot , T , offset , bodytoFeet0)
  
  #####################################################################################
  #####   kinematics Model: Input body orientation, deviation and foot position    ####
  #####   and get the angles, neccesary to reach that position, for every joint    ####
      FR_angles, FL_angles, BR_angles, BL_angles , transformedBodytoFeet = robotKinematics.solve(orn , pos , bodytoFeet)
       
  """move all joints at the next time step angle"""
      #move movable joints
      for i in range(0, footFR_index):
   p.setJointMotorControl2(boxId,...

  Read more »

• Future 3DoF foot sensor.

  Miguel Ayuso Parrilla • 08/27/2020 at 20:52 • 0 comments

  In order to make the robot dynamic in the precisse meaning of the word, we need to have meassurements of the forces acting acting inside the robot, this can be either from the actuators, feet or the IMU.

  This way we can build a robust control algorithm taking into account these forces, such as the Inverse Pendulum model. Basically what we want in here is to implement a physics math model in stead of a direct model like the Kinematics model it implements now.

  This task is not easy to achive, but i found a paper with a very inteligent solution to this problem: Foot design for a hexapod walking robot.
  

  Basically it uses 3 sensitive resistance force sensor, with a proper orientation in order to read the forces at the foot in the 3 different directions.

  What i came with is shown in this pictures, but this is only a quick design with lot of errors at the time of reading accurate meassurements.

  
  Some actual works on the MIT cheetah show how usefull can be this type of foot sensor:
  

  
  

• Calibrating the servos.

  Miguel Ayuso Parrilla • 08/01/2020 at 09:15 • 0 comments

  First of all, you will need to plug all servos to their proper pin, in my case here they are (you can change this for your how setup):

  void connectServos() {
                        //FR
    Servos[0].attach(40); //coxa
    Servos[1].attach(38); //femur
    Servos[2].attach(36); //tibia
                        //FL
    Servos[3].attach(42); //coxa
    Servos[4].attach(44); //femur
    Servos[5].attach(46); //tibia
                       //BR
    Servos[6].attach(34); //coxa
    Servos[7].attach(32); //femur
    Servos[8].attach(30); //tibia
                       //BL
    Servos[9].attach(48); //coxa
    Servos[10].attach(50); //femur
    Servos[11].attach(52); //tibia
  }

  As soon as the servos are corretly attached, what i made in order to put the servos on its correct position is just to dissasembly the legs, i mean, separate the servo output from the its horn, in order to let the servo move freely. This way you can power the servos, let them go to the zero position and the reassembly.

  I wrote a small sketch in order to put the servos on their zero position, you can find it at servo_calibration.py file, this way you can attatch the servo very close to their zero position.

  Then, a more precise calibration is needed, you will need to calibrate the offset of each servo, those offset are defined at angleToPulse.py file. This file only contains the line defining the pulse corresponding to each angle for every servo.
  
  

  Being a line in the form: y = Ax + B. The offset of each servo is defined by B, which mean the pulse at the zero angle.

  If you are using different servos, the slope of the line (A) will be different so you will need to identify it. What i did, is just to take 4-5 meassurement of pulse at different angles and put them on an excel where i calculate the adjucted line from those points.
  

  def convert(FR_angles, FL_angles, BR_angles, BL_angles):
      pulse = np.empty([12])
      #FR
      pulse[0] = int(-10.822 * np.rad2deg(-FR_angles[0])) + 950
      pulse[1] = int(-10.822 * np.rad2deg(FR_angles[1])) + 2280
      pulse[2] = int(10.822 * (np.rad2deg(FR_angles[2]) + 90)) + 1000
      #FL
      pulse[3] = int(10.822 * np.rad2deg(FL_angles[0])) + 1020 
      pulse[4] = int(10.822 * np.rad2deg(FL_angles[1])) + 570
      pulse[5] = int(-10.822 * (np.rad2deg(FL_angles[2]) + 90)) + 1150
      #BR
      pulse[6] = int(10.822 * np.rad2deg(-BR_angles[0])) + 1060 
      pulse[7] = int(-10.822 * np.rad2deg(BR_angles[1])) + 2335 
      pulse[8] = int(10.822 * (np.rad2deg(BR_angles[2]) + 90)) + 1200
      #BL
      pulse[9] = int(-10.822 * np.rad2deg(BL_angles[0])) + 890
      pulse[10] = int(10.822 * np.rad2deg(BL_angles[1])) + 710
      pulse[11] = int(-10.822 * (np.rad2deg(BL_angles[2]) + 90)) + 1050
      return pulse

  
  

• A more stable walking.

  Miguel Ayuso Parrilla • 07/20/2020 at 11:49 • 0 comments

  This log is about polishing the gaitPlanner as you can see in the next video:

  
  

  What is interesting on this video is that no control algorithm is running, but it seems very stable.

  This is achived just by separating stance phase from the swing (as explained in the gaitPlanner.py log), this way i can define an offset between both phases, so running the stance phase at 3/4 of the hole step, makes the robot to hold its weigth on the 4 legs for a short period of time being a bit more stable, just by running the gaitPlanner loop.
  Visually the gait is defined like follows:

  Aditional info about that is that servos got very hot if it runs for more than 10 minutes.
  

• Quadruped robot meets my cat.

  Miguel Ayuso Parrilla • 07/07/2020 at 18:29 • 0 comments

  As a quick update of the V2 robot performing i have introduced it to my cat.
  

  My cat is very introverted and usually doesn't like new things, in this case isn't different but it seems to cause she some curiosity.
  

  The robot performs well, as it uses the last version of the code, the extra weigth of the batteries and raspberry pi is not a problem as the new design is much more lighter and the servos are now powered at 6V in stead of 5V as in the first version.
  

  On the other hand, i have notice the model randomly gives bad solutions running on the raspberry pi, thats why sometimes you see the leg make a strange movement. I haven't identify the problem yet, maybe is my software problem or bufer overflow.
  

  There is no aim to hurt the animal, is my cat omg.
  

View all 17 project logs