By: Ashlee Chang (E&C)

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 #9 is stated as follows:

For the Velociraptor to have the ability to travel up a 6.5-degree incline, an accelerometer shall be implemented to preserve the chassis balance.

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.

Level 2 requirements #11 is stated as follows:

To fully accommodate the movement of a turn, a total amount of 8 servos turning the robot at a an angle of min. 45 ° degrees(referring back to requirement 10) to avoid obstacles.

Level 2 requirements #11 is stated as follows:

To fully accommodate the movement of a turn, a total amount of 8 servos turning the robot at a an angle of min. 45 ° degrees(referring back to requirement 10) to avoid obstacles.

Level 2 requirements #13 is stated as follows:

To establish the wireless connection between the Arxterra Application and the Velociraptor in order to control the robot a Bluetooth communication shall be executed into the system’s robot design.

These requirements were to be met through C++ coding done through Arduino’s software editor. However, due to the load of work in such tight time constraints, the dynamic walking is incomplete and the incline walking code is unfinished. This will be explained in the concluding remarks.

Final Arduino Folder

Below is a link to the final folder. The entirety of the folder will be broken down in this blog.

arxrobot_firmware FINAL

The original Bluetooth folder passed on utilized 20% of program storage memory. Some unneeded files were removed to conserve memory in the arxrobot_firmware folder: battery_selector and fuel_gauge. This brought down the program memory to 14%.

Contents of the final velociraptor folder

Look-Up Tables

As explained in the Walking Code #2 blog, servo angles were moved to Flash memory to compensate for the SRAM limitations. The majority of the code is within the cells from 1-170. Originally over 400 cells long, the LUT size has been optimized in trade-off with more if-then statements throughout the code. The LUT size could be shortened further.

LUT explanation

In cells 1-40 and 81-120 in the excel spreadsheet, the left leg and right leg will take a step. In 41-80 and 121-160, all leg servos are re-initializing as the head and tail sway directions. Lastly, 161-170 are dedicated to pre- and post-turning arrays. The point here is to bring the body closer to the floor so that the velociraptor could grasp the floor more roughly while turning.

Turning

For this blog, the turning code has been implemented. There were several approaches the group has brainstormed to accomplish this. By accident, it was discovered a turning mechanism could be a dragging mechanism where one leg drags behind as the other scoops backwards. It not only proved to be an effective turning method, but also the LUTs used for walking were also capable here. Originally, the turning code for each foot was over 100 cells long and took up 65% of program storage space. By using the same LUT values for static walking and turning, the space was optimized so that only 48% of program storage space was used.

Program storage space optimization results

Object Detection

The velociraptor head measures 7 inches long. Thus, it was coded so that any object 6+7=13 inches in front of the ultrasonic sensor (half  of a foot from the head) would prohibit the velociraptor from moving forward. The user would have to hit the left or right turn button and go on from there.

Upon passage clearance, the forward button will work

Bluetooth

Only four buttons were needed for our project: forward, left/right turn, and dynamic walking. Only the third and fifth element of the package were used in our particular application, which basically dictates which button is pressed. Additional coding was needed to make up for the fact that the Arduino Micro is a Leonardo device. Below shows one of the many modifications made by the S&T division manager to allow our Bluetooth to communicate with the Arxterra app.

Leonardo device modification

Unfinished Business

Time constraints disallowed the further progress of the velociraptor as of the due date. In the LUTS, cells 171-355 (un-optimized size) are dedicated to dynamic walking. It was an in-progress task that was ultimately unsuccessful. A demonstration could be done, but the user would need to hold the robot as it jerks from side to side. It was difficult to code the velociraptor using momentum to keep afloat–finding that sweet spot between balance and imbalance.

The analog accelerometer is capable of sensing incline and using that data to initiate a new walking code that would bring the center of mass towards the head. This would require a completely new walking code with new angles: due to the geometry of the legs, just “re-positioning” all leg servos by the same angle would not in effect allow the velociraptor’s original walking code to walk any longer. A new set of angles need to be discovered where these changing angles would stay perpendicular to the floor. Not to mention, there arises a problem on how the velociraptor will react once it slowly reaches the 7* incline (i.e. before hitting the full 7* incline, the velociraptor already starts tilting backwards).