Spring 2016 Velociraptor: Material Trade-Off-Study Update

/in , /by

Requirements needed to fulfill:

  • Project Level 1 Requirement:
  1. According to the given course that the robot is to complete, the Velociraptor shall travel on multiple surfaces. Refer to course analysis for more detail.
  2. The Velociraptor shall be able to statically walk on all surfaces of the course
  3. The Velociraptor shall be able to dynamically walk on flat surfaces of the course.
  4. The Robot shall statically travel up a 6.5-degree incline according to the course analysis
  • Project Level 2 Requirement:

6. To maintain balance while performing static walking, a head and tail shall be implemented to the chassis of the           Velociraptor to even out the shifted weight when standing on one leg and           thus meet the Project Level 1, requirement

8. In order for the Velociraptor to travel on two different surfaces, the material that will be placed on the feet shall           have a coefficient of friction of more than 1.0 in accordance to the                      Course Analysis as to refrain from slipping,               and thus meet Project Level 1, requirement 3.

Actual experiments will be done to verify the feasibility of the design using our 2nd prototype.

Experiments:

  1. Material Trade – Off- Study:

a) First Experiment included the feasibility of using 3D filament Polylatic Acid (PLA) for our final robot. When we started building our 2nd prototype, including the head and tail, we’ve decided to distribute the weight of the body by placing the batteries toward the head and tail to put less strain on the servos. By using this design, we will be able to minimize weight of the chassis of the robot and use the weight of the head and tail to shift center of mass.

prototype

But putting more weight toward the head and tail, caused the bottom piece of the body that connects the head to start cracking which made us do a material trade-off-study to determine the right material for our robot.

 

material1

Trial using PLA filament

 

material2

Trial using Aluminum

 

The printing the bottom piece using the 3D filament weighed 13 grams compared to Aluminum piece which weighed 19 grams. This not only shows the feasibility of using Aluminum for our bottom piece to maximize the weight on the head and tail, verifying project level 2 requirement 6 to implement head and tail on the chassis to shift the center of mass to balance when it’s performing static walking.

 

b) The second experiment was conducted in order to verify the 3D filament PLA is feasible perform static and dynamic walking on various surfaces without slipping.

Level 1 requirement 6 states the robot should perform static walking on a 6.5 degree incline, so we’ve created inclines using various degrees to determine if the robot was able to balance and refrain from slipping at a minimum of 6.5 degrees. For our experiment, we started off by creating a slope from 4.5 degrees to 13.7 degrees and tested to determine the degree the robot starts slipping.  In order to create a similar static friction of the course, we have implemented a carpet on the incline. For experimental measurement, we’ve used a protractor to measure the angle of the slope, and for the theoretical measurement, we’ve used the length and height to calculate the slope:

inlcine

Both feet on Ground:

friction test chart 1

The chart above shows the acceptability of the 3D model, when we assembled the robot, it was able to stand with both foot on the ground up to 15.7 degrees without slipping or falling.

Figure 3b

Placed sideways on a 8.7 degrees incline, successfully balancing and refraining from slipping.

Figure 3a

Robot placed on a 8.7 degrees incline without slipping or falling.

 

 

One foot on Ground:

 

friction test chart 2

When the robot is performing static walk on incline, we’ve tested if it was able to balance on one foot without falling or slipping. As shown above, the experiment showed the robot was able to balance on one foot up to 9.7 degrees incline.

OLU 3a

By shifting the weight of head and tail toward the shifting leg, the robot is able to stand on one foot as if it’s performing static walk. It’s able to stand on a 8.7 degrees incline without slipping nor falling.

 

Conclusion

Using a thicker material for the bottom piece will not only increase printing time, but also create less space for our components to fit. But by using Aluminum for the bottom piece of the body to hold the head and tail, not only will it be able to hold up to 483 grams but also we will be able to keep enough space in the middle to mount the PCB. The test to verify the material used to refrain the robot from slipping have been successful. The robot was able to stand on both feet and on one foot up to 9.7 degrees without slipping. When the robot has to stand on an incline of more than 10 degrees, we will have to reconfigure the robot’s ideal standing position to slightly lean forward in order to make sure the center of mass stays in the middle of the robot’s body.

Spring 2016 Velociraptor: Updated Walking Code #2 (Flash Memory)

/in , /by

By: Ashlee Chang (E&C)

Table of Contents

Fulfilling Requirements

Level 1 requirements #4 is stated as follows:

The Velociraptor shall be able to statically walk on all surfaces of the course.

Level 2 requirements #10 is stated as follows:

An ultrasonic sensor shall be implemented to the build of the robot to detect obstacles at a range of 20 cm.

The Arduino software, which uses much of C++ programming language, will be used to construct and upload the code onto the Arduino microcontroller. The MB1030 ultrasonic sensor was implemented in this updated code.

SRAM Limitations

a

Arduino memory sizes

Looking at the Arduino micro specifications as listed on their website, it’s noted the SRAM (static random-access memory) memory is a mere 2.5 kB compared to flash memory at 28 kB (taking into account the bootloader space). The previous walking code could potentially “blow up” the microprocessor using while condition loops and many variables. To avoid this problem, moving the servo angles to flash memory is not only vital, but proved to be more convenient.

The How-To

The first step is to transfer all servo angles over to an excel spreadsheet. It is important that in each column, all of these angles should be designed to be read at the same time. For example, in column 1, we see that front left = 110, black left = 70, front right = 92, etc. That means that at this point of time of 0 seconds, all servos will read at these respective angles. These indexes are related to the time the velociraptor is operating at. The velociraptor has 160 cells for each servo. The whole point of using excel is to better organize the angles and ensure that every servo has the same number of total indexes. For the second prototype, the new legs had different dimensions, thus some adjustments were required for the servo angles.

aaaa

Servos and their servo angles

Next, save this excel file as .CSV. Re-open this file, but this time using notepad.

xxxxxxx

.CSV file opened in notepad

Now it is easy to grab these angles separated by commas and insert them into an array to be stored in flash memory. Next, on the right-hand side of the Arduino software, there is a down arrow button. Click this to expand some options, and click New Tab. Name this file according to the particular servo, and end the file name with “.h” to ensure it will in fact be an h-file. For example, one .h file the velociraptor used was flashFL.h (FL for front left servo).

asdf

Next, add “const unsigned int _[] PROGMEM = {_};” in this new .h file tab. The first _ will be the name of your .h file. The second _ will be the array copied and pasted from the .CSV file opened with notepad for the associated servo angle array. The command PROGMEM stores data in flash memory as opposed to SRAM memory.

123

Using PROGMEM in the .h file

All of these .h files should be in the same folder as the main code. Double check this, else the main code will not know where to look for these files. The .CSV file is not necessary to keep in the main folder, but is easy to refer back to in case any changes are to be made.

asdfd

.h files in the main code folder

To allow the main code to utilize these arrays stored in flash, “#include_” must be stated in the beginning of the main code.

1343223

#include for the .h files

Last but not least, the array values are called from flash memory based on its index value. Use the function pgm_read_word(&_[i]); to access this data.

12321321

Reading from flash memory using indexes

Updated Walking Code

Below is the updated walking code.

WalkFLASH_ultrasonic

Note how much cleaner and shorter the code is compared to using dozens of while loops to control the eight servos of the velociraptor.

dddd

Updated walking code using flash memory

The main loop reads from all of the servo .h file arrays at one index at a time, then written to all eight servos at the same time. There are a total of 160 indexes per file, so after 160 iterations, the velociraptor will have taken two steps (one with each leg). Moving to flash memory not only saves SRAM memory, but also makes editing any servo angle at any point of time a piece of cake. A delay of 20 ms was chosen, but this could be adjusted to make the velociraptor walk slower or faster.

Also updated for the CDR presentation was implementation of the ultrasonic sensor. Every 40 cells read from the servos, there would be an object detection check. If there is an object within 10 inches of the ultrasonic sensor, the velociraptor would stop.

Also new to the code is the newly added head and tail. In order for the velociraptor to take a step, the center of mass must be moved from the center body to directly on top of the leg that will still be on the floor. Below is a table explaining the 160 cells of each array. For the first 40 cells, the left leg will take a step. This means the head and tail are already turned to the right so that all of the velociraptor weight is on the right leg that is on the floor. For the next 40 cells, both legs are on the floor as the servos both reinitialize in reparation for the next step while propelling the body forward. Because both legs are on the floor, the head and tail can now move from right to left. Etc.

rtrgr

Implementing the head and tail

Spring 2016 Velociraptor: Circuit Schematic & Servo Load Test

/in , /by

By: Ashlee Chang (E&C)

Table of Contents

A Clean Electronic Setup

breadboard

Breadboard testing

The electronics journey goes as so: Fritzing diagram, breadboard testing, circuit schematic, and then PCB (printed circuit board) fabrication. All electronic components are Arduino microcontroller, four batteries, eight servos, Bluetooth, ultrasonic sensor, and accelerometer. Notably, there are quite a bit of components, meaning a lot of wires needed to interface between them all. That is why the team decided that most of the wiring would be implemented on the PCB to avoid a messy project. Also, the microcontroller will be mounted directly on the PCB for this very purpose.

Servo Load Test

Servos in general draw quite a sum of current, and that current draw is proportional to the load (weight) the arm has to push against. A voltage regulator will be needed for the velociraptor, so it’s essential to see approximately how much current is drawn by these powerful servos so an appropriate regulator can be chosen. A test was conducted to see the servo load versus current draw.

xx

Servo load and current test

A bucket containing miscellaneous materials to reach a particular weight was used and weighed on a scale. Afterwards, a string was used on the bucket and attached to the servo. A simple sweep code was installed on the servo to work against this load. An ammeter was inserted into the servo and power source loop.

xxx

Servo load and current results

The results were documented in the above table. The velociraptor currently weighs 544g (not taking into account the PCB, microcontroller, sensors, and Bluetooth). Thus, the project will weigh around a total 570g-600g. Taking the current draw of 0.3A at 506g from the table, this brings the current draw of eight servos at 2.4A. If the project is estimated to be 600g, the total current draw should be close to 3A, not taking into account current going to other parts of the circuit. Thus, the voltage regulator must be capable of handling over 3A.

Voltage Regulator

The voltage regulator is the only major component on the circuit schematic. Choosing a proper one was difficult. A decision between an LDO (low dropout voltage) voltage regulator versus switching regulator was contemplated. The switching regulator is actually highly efficient compared to the LDO voltage regulator. The lesser the inefficiencies, the lower amount of energy will be wasted as heat. Because the velociraptor shall be designed as a child’s toy, hot electrical pieces is a definite no-no that must be avoided for the health and safety of the user. With all switching regulators, there needs an inductor in the suggested schematic, which requires specific placement of the schematic in terms of distance on the PCB. Finding a switching regulator with an internal inductor proved to be impossible. In addition, there are not many switching regulators capable of stepping down small voltages. In the velociraptor’s case, the voltage had to be stepped down from 7.4V to 6.0V, which is only a change of 1.4V. Due to the complexity of switching regulators, the team decided on an LDO voltage regulator.

Some spec considerations that must be taken into account were: 5A maximum current output, input of 7.4V, output of 6V, capable of stepping down 1.4V, efficient, and through-hole (the smaller the package size, the hotter the component can get). The voltage regulator agreed on was MIC29512. Some additional features include current limiting protection, thermal shutdown, and an enable input pin that can be used to turn off the voltage regulator when not in use.

x

MIC29512 Voltage Regulator

Heat Sink

If the voltage regulator were to be a surface mounted piece, some copper embedding must be implemented. However, seeing the voltage regulator is a through-hole TO-220 package, a screw on heat sink can be used. For calculations based on the datasheet, the math is as follows: Rtsa = [125 – 50] C / 3W – 2 C/W – 1 C/W = 22 C/W. Any heat sink under 20 C/W would be ideal, but one with a specification of 9.6 C/W was chosen because, after all, this is a child’s toy.

xxxx

Heat sink choice

Eagle Circuit Schematic

schematicfinal

Velociraptor circuit schematic

The final circuit schematic is shown above. Both two batteries will be in series, and those two are in parallel. The resistors in between are used to help with any possible offset in between the two battery pairs. Transistors were placed to use the enable pin. A large capacitor needs to be next to the batteries. A TO-220 package was made for the schematic, and the recommended schematic was constructed based on the MIC29512 datasheet. The respective resistors used were calculated to output 6V on the voltage regulator. The batteries were connected to both the microcontroller (which can take inputs up to 12V) and the voltage regulator. The regulator feeds the servos as to get to that optimal voltage of 6V. The Arduino micro is placed directly in the schematic. Lastly, some simple connectors were used for the sensors, actuators, and Bluetooth.

UFO Torque Test Spring 2016

/in , , /by

Posted by: Luis Valdivia (Project Manager

By: Anthony Becerril (Systems Engineer)

Table of contents:

  • Test objective
  • Test Procedure and Criteria
    • Preliminary work
    • Procedure
  • Results
  • Conclusion
    • Video
  • Appendix

 

Test Objective:

To create stable flight, the current quadcopter must not have yaw rotation being created by the Electric Ducted Fans (EDFs). This torque test will measure the necessary torque to counter the yaw rotation that exists. Theoretically, this torque will eliminate the yaw rotation and the counter torque will be produced via an additional fan to be implemented.

 

Test Procedure and Criteria:

Preliminary Work:

The torque seeked in this experiment will be calculated as follows:

Torque = F*r=F*(D/2)


r: radius; distance between center of rotation
D: diameter

F: force; force point

Figure 1.1 Representation of Torque setup:

Torque

Figure 1.2 Set up used on UFO quadcopter:

IMG_20160403_161323392

The setup built for this testing required the following:

  • A pulley system to support weight like that of a full water bottle
  • A lazy-susan-like platform for quadcopter to spin on
  • An adjustable weight to vary on pulley during testing (i.e. water bottle)
  • A latching system to prevent the quadcopter from flying

 

Procedure:

The procedure to execute this test is as follows:

  1. Have fully charged battery ready [Appendix A]
  2. Upload corresponding Arduino IDE code to Arduino Uno
  3. Properly connect all necessary wires on quadcopter except for the battery [Appendix B]
  4. Place the quadcopter onto the set up turntable. Make sure the hooks are properly attached
  5. Have pulley weight properly attached to one of the EDFs
  6. Have potentiometer set to max before plugging in battery
  7. Plug in battery
  8. Tune potentiometer to turn on angle. Wait for calibration as indicated by the beeping code [Appendix C]
  9. Continue tuning potentiometer to higher thrust. Observe yaw rotation.
  10. If rotation exists, add more water to bottle. Continue this step until no rotation
  11. Take final weight and calculate final torque using the formula:

Torque=9.8ms2*radius *weight

Radius = 4.5” → 0.1143m

Weight= weight of object in Kg

 

Results:

Torques that were listed must have demonstrated rotation on the setup to be considered valid for our data collection.

 

Table 1.1 Data collected from eight tests:

Test # mass(kg) of bottle after throttle % from pot Voltage (V) to the ESC Torque (kgf*m)
in class demo 0.0609 43.12% 2.16 0.068216526
1 0.018 25.90% 1.30 0.02016252
2 0.035 34.70% 1.74 0.0392049
3 0.04 40.33% 2.02 0.0448056
4 0.033 32.26% 1.61 0.03696462
5 0.042 39.10% 1.96 0.04704588
6 0.046 40.86% 2.04 0.05152644
7 0.076 44.77% 2.24 0.08513064

Figure 1.3 Plotted points torque v. voltage percentage from 5v to the ESC:

Percentage

Figure 1.4 Plotted points torque v. voltage provided to the Electronic Speed Controllers:

Voltage

Conclusion:

In conclusion we were able to gather multiple data points in our torque tests. Plotting our data points in excel, we can see the exponential trendline of the relation between torque of the quadcopter and voltage provided to the Electronic Speed Controller. These data points will help us understand how to maintain stability by producing our own counter torque. Using the 5th fan approach, we can determine what find to buy, based on necessary thrust to counter yaw torque. 

Click here for a video of the torque set up in action!

Appendix:

A. Battery Charging Manual

B. Wiring Diagram for Torque Test

Figure 1.5 fritzing diagram for torque test electronics:

FRITZING

Figure 1.6 cable tree of electronics:

WIRING DIAGRAM

C. Electric Speed Controller beep code

             Beep codes can be used for troubleshooting ESCs.

Spring 2016 Velociraptor: Center of Mass

/in , /by

By: Mingyu Seo (M&D)

Introduction:

Humans use center of mass to balance, for example when we are standing on both feet our center of mass would be at the center of our body, but when we try to position or balance on one foot, we shift our body closer to the supporting leg which also shifts our center of mass to find balance. Our team has incorporated this idea to our robot in order to successfully perform both static and dynamic walking. Solidworks can calculate the center of mass and the total mass of our 3D model based on the design and dimension created by the Manufacturing & Design Engineer. Our level 1 requirement shows the robot should be able to complete the course using both static and dynamic walking. In order to successfully complete a static walk, the robot should be able to balance itself on one leg while the other leg takes a step forward. When we’re lifting one leg up it is very important for the center of mass to be as close to the most supported leg to maintain balance.

Method:

Solidworks can calculate the center of mass by simply changing the position of our robot. When we are performing a static walk, we will lift one leg up and use our head and tail as a counter mass to bring the center of mass closer to the supporting leg. The pictures shown below will explain how the center of mass shifts when the robot takes a step.

 

Screen Shot 2016-04-02 at 6.48.00 PM

Figure 1: Standing on both feet

Screen Shot 2016-04-02 at 6.48.10 PM

Figure 2: Lifting right leg

Screen Shot 2016-04-02 at 6.48.20 PM

Figure 3: Lifting left leg

Figure 1. Shows, when the robot is standing on both feet, we could see that the center of mass (pink dot) is position right in between the two feet. Figure 2. Shows when we lift our right foot, we position our head and tail left in order to create a counterweight for our center of mass to be closer to the supporting leg (left leg). Lastly, Figure 3. Shows when the left foot is up, we would position our head and tail to swing right to move our center of mass closer to the right foot. Figure 2. & Figure 3. Shows that the center of mass hasn’t reached fully above the supporting leg, but this error was caused by the insufficient weight of the head and tail. Our design includes distributing our battery between the head and tail in order to minimize weight load on our body as well as create enough counter weight for our robot to perform static and dynamic walk. For 2016 Velociraptor team, Center of mass testing using Solidworks have helped to validate our Level 2 Requirement (#6) of maintaining balance while performing static walk.

Spring 2016 Velociraptor: Bluetooth & Arxterra

/in , /by

By : Camilla Nelly Jensen (Systems Engineer)

In order to meet the project level 2 requirement 13 for the Velociraptor, the Bluetooth module shall be connected to the microcontroller to establish a wireless communication with the Arxterra application that is installed on an android device. Below are the instructions on how to establish this communication.

1.Download Arxterra application to Android device

2. Build Bluetooth configuration on breadboard

  • According to the System Recourse Map, the HC-06 Bluetooth module is connected to the following pins on the Arduino microcontroller:
    • HC-06 Ground (GND) pin to Arduino ground(GND).
    • HC-06 power (Vcc) pin to Arduino 5 V – To power Bluetooth module.
    • HC-06 TX/TXD pin to Arduino digital pin 0 (RX)- to transmit data from Arxterra app to MCU(Velociraptor).
    • HC-06 RX/RXD pin to Arduino digital pin 1 (TX)- for Arxterra app to receive data from MCU(Velociraptor).
    • The STATE and EN pins will not be used.

Bluetooth module

Figure 1:

Figure 1 displays the Bluetooth module that will be used to establish the wireless communication to the robot. On the Bluetooth module, the RXD and TXD pins are used for sending and receive data. The module operates at 3.6V to 5V. Receiving data via the RXD pin operate at 3.3V from Arduino.

Receiving data via the RXD line on the Bluetooth module from the Arduino can potentially burn the device. The Arduino transmits a higher voltage than the Bluetooth module can handle, therefore, modification needs to be done. The TX line of the Arduino transmits a voltage at 5V to the receiving pin RXD on the Bluetooth module, however,  the RXD pin can only be operated  at 3.3V. By implementing a voltage divider, this will drop the voltage to 3.3V coming into the RXD pin of the Bluetooth device and thus, protects it from being damaged.

Screen Shot 2016-04-02 at 6.36.16 PM

Figure 2: Voltage Divider Equation – credit to 42 Bots

Figure 2 displays how the voltage divider is set up in order reduce the voltage from TX to the RXD pin of the Module.

The Bluetooth module uses  3 x  10k ohm resistors in series and the calculations are shown below in figure 3:

 

Voltage divider for robot

Figure 3: Voltage divider calculations for Velociraptor

3. Establish Bluetooth connection between Android device and Arduino

The Bluetooth schematic on the breadboard is shown in figure 4.

 

Bluetooth setup

Figure 4: Bluetooth setup

  • The Bluetooth module uses the Arduino IDE code which has the latest version of the Arxrobot firmware. The codes can be downloaded from Github.
  • Under the Arxrobot_firmware tab, you find the code to upload to the Arduino, to be able to connect to the Bluetooth module that is connected to the Arduino Microcontroller

Screen Shot 2016-04-02 at 6.39.26 PM

Figure 5

  • The Bluetooth module utilizes the code above in figure 5 to connect to the Arduino. This code is uploaded to the Arduino microcontroller to recognize the serial communication with the Bluetooth module.
  • The Bluetooth is connected to the Arduino which is powered by a computer. The Bluetooth module’s red LED blinks when the module is turned on, the LED stop blinking when communication with Android device is established.
  • To pair the module with the Android device go to Settings >> Bluetooth and select the HC-06 module and type in the default pairing code: 1234.
  • In the Arxterra application, ARXROBOT the Bluetooth symbol on the top right corner is selected and tap connect to the paired device the Bluetooth module HC-06.
  • Once the communication is successfully established; the Bluetooth symbol on the top right corner of the ARXROBOT app turned blue (white when there is no connection) and the red status LED on the Bluetooth module stop blinking. The established communication is shown in figure 4 where the red status LED is on.

4. Confirm Bluetooth communication by turning on 4 LEDS on the breadboard via the joystick on the Arxterra app

The Velociraptor shall be able to walk forward and turn when the robot detects obstacles in order to avoid a collision. Therefore, the joystick on the ARXROBOT qualifies as the best solution for control pad as it provides four buttons of control. The joystick that’s made up of four buttons makes its possible to attach one command to each button, ie. four commands: forward, turn left, turn right and backward. However, the 4th button is not necessary, as we don’t intend to implement a backward walking command. In order to access the four different buttons, a simple code turning on four LEDS was written in the Arduino IDE, so that the forward button in Arxterra app will turn on LED attached to pin 8 and so on. This test was made so that the Electronic engineer decode the signal into subcommands of move forward, turn to either side etc.

Screen Shot 2016-04-02 at 6.40.38 PM

Figure 6

Figure 6 displays the Arduino IDE code that will control each LED by one of the four buttons on the joystick on the Arxterra app in the order of:

  • Forward button will turn on LED attached to pin 8
  • Right button will turn on LED attached to pin 9
  • Left button will turn on LED attached to pin 10
  • Back button will turn on LED attached to pin 11

Note: Before uploading the code to the Arduino remember to detach the Bluetooth module from the breadboard as it will interfere with the upload and causes error. Re-attach when the code finishes uploading.

Click here for the video showing the communication between the Bluetooth and the Arxterra Application.

References:

 

Spring 2016 Velociraptor: Calculations and Verifications

/in , /by

By: Camilla Nelly Jensen (System Engineer)

Requirements:

6. To maintain balance while performing static walking, a head and tail shall be implemented to the chassis of the Velociraptor to even out the shifted weight when standing on one leg and thus meet the Project Level 1, requirement 4.

maintain balance pic

Figure 1:  http://design.tutsplus.com/articles/human-anatomy-fundamentals-balance-and-movement–vector-20936

Verification [6]:  Figure 1 shows, the center of mass is not supported when taking a step. Therefore, following the concepts of TITRUS III a head and tail shall be implemented to the body of the Velociraptor to shift the center of mass onto the foot so that it can maintain balance while walking.

7. For the Velociraptor to perform dynamic walking servos moving at a speed of 0.101 sec/12.5° shall be implemented to the chassis and thus meet the Project Level 1, requirement 5.

Verification[7]: Assuming that the legs of the Velociraptor will not exceed 10 cm in length, using physics equations we can estimate the time each leg of the Velociraptor has to perform a dynamic step:

Screen Shot 2016-03-31 at 8.10.17 PM

TITRUS first step of dynamic walkTITRUS Second step of dynamic walk

Researching TITRUS III performing dynamic walk as shown in figure 2. The angle of the right leg, performing first part of the dynamic step is calculated to 45°. The next part of the step the angle is calculated to 32.5°. Therefore subtracting these two angles we get the angle at which the TITRUS III pushes the right leg forward to perform one dynamic step to 12.5°

Therefore we estimate that the servos needed for the Velociraptor to perform dynamic walk will have to push the each leg forward at an angle of 12.5° per 0.101 seconds.

8. In order for the Velociraptor to travel on two different surfaces, the material that will be placed on the feet shall have a coefficient of friction of more than 1.0 in accordance to the Course Analysis as to refrain from slipping, and thus meet Project Level 1, requirement 3.

Verification[8]: The highest coefficient of friction of the surfaces that the Velociraptor will travel on is 1.0 from the friction between rubber and a solid.

10. In order for the robot to detect obstacles at a range of 20 cm in its path, ultrasonic sensors shall be implemented to the build of the Velociraptor and thus meeting the Project Level 1, requirement 7.

Ultrasonic sensor calc.

Figure 3: Ultrasonic Proximity sensor calculation

Verification[10]: The Velociraptor shall detect obstacles (Binder) at a range of 20 cm in its path in order to maneuverer around it without hitting the obstacle as calculated in figure 3 above. This requirement anticipates the servos to turn the robot at an angle of 45° rather than 30° in order to gain enough free space of 8.57 cm to maneuver around the obstacle without hitting the corner X of it.

11. To fully accommodate the movement of a turn, a total amount of 8 servos turning the robot at an angle of min. 45 ° degrees(referring back to requirement 10) to avoid obstacles shall be implemented to the Velociraptor and thus meeting the Project Level 1, requirement 8.

Verification[11]: An assumption of the weight of the Velociraptor’s head has been set to a total of 380g(130 g from batteries placed on the neck, 200g chassis and 50g for material for chassis of head of aluminum).

Researching from last semesters MicroBiped they used the MG92B servos which provided torque of 3.5kgcm at 6V. Dividing that with the length of the legs that will be equal to the length of neck(and tail) of 10cm equals: 3.5kgcm /10cm = 350g

This shows that one servo only provide torque enough to move a mass of 350g and not the estimated weight of 380 g for the Velociraptor’s head.

Hence this semesters Velociraptor will utilize a minimum of 2 servo per head, 2 servos per tail and 2 servos per each leg adding up to a total of 8 servos to insure that adequate torque is provided to fully accommodate the movement of a turn.

Spring 2016 Velociraptor: Walking Code #1

/in , /by

By Ashlee Chang (E&C)

Table of Contents

Fulfilling Requirements

Level 1 requirements #4 is stated as follows:

The Velociraptor shall be able to statically walk on all surfaces of the course.

The Arduino software, which uses much of C++ programming language, will be used to construct and upload the code onto the Arduino microcontroller.

Coding Summary

This blog will focus on the main walking code for the velociraptor. In the future, a collection of codes must be integrated into the final code in order to meet all the level one requirements. Below is a complete list of the main walking code and all future codes with a short description:

  1. Main walking code: This is for static walking (i.e. upon telling the velociraptor to stop, the velociraptor will be able to balance in its current state).
  2. Walking fast: The main walking code will be modified to have shorter delay times. In addition, the head and tail will not swing in full motion, as the velociraptors momentum will be used for balance.
  3. Sensing – objects: Upon close object detection using the ultrasonic sensor, the velociraptor will halt.
  4. Turning: The user will be able to tell the velociraptor to turn, whether it be because the velociraptor halted in front of an object or at any given time.
  5. Sensing – incline: Upon sensing an incline using an accelerometer, the velociraptor will adapt with a new walking code with its body closer to the floor and smaller steps for balance.

Calibration

callibration

Respective servo degrees of freedom

Servos are limited to movement from 0* to 180*, unable to make a full rotation. Thus, the servos had to be calibrated in order to move in the desired directions. In order to calibrate the servos, they were first connected to the Arduino microcontroller and written to 90*. This way, it is certain that any movements 45* in either direction from this initial calibration will be possible. After calibration, the velociraptor legs were fastened on.

Flaws of the MicroBiPed

Below are visualizations of the Japanese velociraptor Titrus III (our team’s goal), the MicroBiPed of last semester, and the preliminary walking code for the velociraptor.

ezgif.com-video-to-gif (1)

Titrus III walking (https://www.youtube.com/watch?v=GxVv4WNlXMA)

ezgif.com-video-to-gif (2)

MicroBiPed walking (https://www.youtube.com/watch?v=3sMzl35wO98)

ezgif.com-video-to-gif

Velociraptor walking (preliminary code)

Observe the Titrus III. As the back leg is taking a step, the front leg is stationary. However, even though the front leg is stationary, the servos are still moving! As noted in the MicroBiPed and the preliminary velociraptor walking code above, the non-walking-leg servos are not moving. What does this in turn cause? As one foot is taking a step forward, the other foot gets dragged behind, hindering the robot from effectively moving forward. This is the biggest flaw of the MicroBiPed in terms of coding. The purpose of the moving servos of the stationary leg is to propel the velociraptor’s body forward, as opposed to a stationary leg without moving servos dragging the velociraptor behind. Although this causes great complexity in the coding for walking as all four servos are moving simultaneously (and seeing that codes are read line by line), implementing this improvement will no doubt result in an actual walking velociraptor.

Approach

approach

Process for coding the walking

Above shows a block diagram used in the process of compiling the walking code. The velociraptor servos are initialized at [110* 70* 70* 110*] for [front-left back-left front-right back-right]. It is equally important to keep the velociraptor tall enough as to take larger steps and short enough as to ensure the velociraptor keeps balance. From this initial position, a succession of degrees were written for the velociraptor to take a step. The front servo ensures the foot will rise in the air, and the back servo ensures the foot will push out for a large step. After a simple stepping code, a code had to be made for moving the servos of the other leg while the first leg was taking its step. With such complex math due to the different leg sizes and multiple moving pieces, this part was carried out by trial and error. The front and back servos had to complement each other as to keep the foot completely parallel to the floor. Implementing both the step and the perpendicular leg movement in one leg was quite simple, but integrating this motion in both legs at the same time proved to be quite difficult. Thus, a timing diagram was made. Observing that the Titrus III takes about 3.2 seconds for one full walking loop, the velociraptor’s walking loop was set to be close at 3.6 seconds. Initially, the walking code loop conditions were based on a certain servo’s angle. However, as the looping became more complex with multiple servos moving at once, the looping condition variable was changed to one that kept track of time (i.e. the delays), thus utilizing the timing diagram. Lastly, each servo within a loop had to move at a different pace, whether it be double, triple, or even 1.5 times the rate of another servo in its loop. Thus, loops had to be nested within each other, or some servos had to increase or decrease by more than just +1 or -1 degree at a time, in order to achieve the desired degree changes per section of time.

Timing Diagram

timing

Timing diagram

Because all four leg servos will be moving simultaneously, a timing diagram was made as to allow a timing variable be the looping condition in the velociraptor code. A full looping cycle was set to be 3600 ms, broken into 9 segments of 400 ms (meaning there are 9 total main loops in the walking code). The diagram lists the total time elapsed for a full walking loop (which is used as the timing variable in the code), delay in between each segment of code, the degrees of each servo at a certain time, and the change in degrees of each servo over the period of 400 ms. The yellow and blue font colored numbers indicate when that leg is taking a step (when the foot is on the floor, when the foot is in the air, and when the foot is on the floor again). Note there is 400*3=1200 ms in between the stepping of one foot and the other, which will be saved later for the movement of the head and tail responsible for relocating the center of mass on the stationary foot.

Debugging

Although the servos have the capability to rotate from 0* to 180*, the velociraptor leg joints are connected in such a way that limits the servos degree of freedom even more-so. Any slight error in the coding that moves the servo to an angle that the leg joints aren’t meant to handle can cause damage to the servo gears, or if the torque is powerful enough, could potentially snap the legs of the velociraptor. That is why debugging the program on the Arduino without physically connecting power to the servos is important. Serial.print( ) was frequently used to test the program and ensure all variables were as expected.

debugging

Debugging the program and checking the serial monitor

Code Structure

The first section of the code includes the servo library and creates (currently) four servo objects to control each servo. The second section of the code (void setup) initializes variables, attaches the servos to the Arduino pins, writes the initialized angles tot he servo, and includes a Serial.begin(57600) for debugging purposes. Also, the first segment of the walking code is placed here. This is because the velociraptor will initially be in a stance where it is balanced on two feet with the head and tail both facing forward. It is coded so the right foot will take a step first while the front-left and back-left servos are kept at 110* and 70*. Finally when the front-right and back-right servos reach 85* and 140* (at total time = 0), the loop will begin. In the third section of the code (void loop), the left foot will take a step while the right foot re-initializes while keeping perpendicular to the floor. Then, the right foot will take a step while the left foot re-initializes while keeping perpendicular to the floor. This segment of the code repeats.

Walking Code NotePad File

Results

Compare the preliminary walking code versus the improved walking code (see first GIF of the velociraptor). The first prototype has some joint dimensions that are slightly off, and some imperfections on connections and drill hole sizes, thus the velociraptor appears to walk lopsided. Rest assured, the angle movements on each leg mirror each other exactly in the code, which will reflect on the next prototype and/or final product. The prototype must be held as the walking takes place, as there is a head and tail installed for balance. Examine how the stationary foot’s moving servos push the velociraptor forward.

ezgif.com-video-to-gif

Improved walking algorithm

Spring 2016 Velociraptor: Microcontrollers

/in , /by
By: Camilla Nelly Jensen (System Engineer)
 unspecified copyTable 1: Comparing the Microcontrollers
Table 1 compares two possible microcontrollers which acts as the brain for the Velociraptor. The microcontrollers will be used to connect all the components required for the Velociraptor. The chart compares pins available, input voltage, dimension, weight, memory, and average price.
The amount of pins necessary for the Velociraptor has been estimated from the systems resource worksheet which allocates the pins of the components such as sensors, servos, and the Bluetooth module.
The Velociraptor contain a ultrasonic proximity sensor that will be connected to 2 PMW pins, an accelerometer that need 3 analog pins, and 10 digital pins, 8 pins for the 8 servos and 2  pins for the Bluetooth module. The input voltage is the key to understanding the amount of voltage that the batteries must supply. The dimensions and weight are important to create a lighter and smaller body for the Velociraptor.
Minimizing the cost of the microcontroller is important as sought out in the cost report. After comparing the microcontrollers, the group decided on using the Arduino Micro because it has the lowest weight and cost and smallest dimensions and thus is the more cost effective choice for the Velociraptor.