Schematic

By Renpeng Zhang

Chassis Schematic

Schematic

Description

For the chassis eagle schematic, I choose to use two PCA9685 I2C expanders because one doesn’t have enough PWM pins for all our needs. We also used six VNH2SP30 motor driver for our motors. We use the PWM input from the I2C to the PWM pin in the motor driver. We left the shaft encoder pins on the second expander for the reading of the values for the RPM of the motor. We have left the pins for the current sensing on each of the motor driver so that they will be connected to the analog input of the Arduino to get the current of each motor.

Solar Cell Wire Layout

By Edgardo Villalobos

Wire layout out for the solar panels.

Table of Contents

Top View

Bottom of panels

1.

2.

3.

Top Level

 

 

S17 Prosthetic Arm: Attachment Module Test

This is a test for a prosthetic arm attachment that only require’s straight forward attachment to the humeral bone of the customer instead of the use of an uncomfortable over the shoulder strap piece.

Spring 2017 BiPed – Arxterra Control/Code

By: Jacob Cheney (Systems)

Approved By: Alexander Clavel (Project Manager)

Table of Contents

Introduction

During the final mission, where the BiPed will compete in the end of the semester game, it is required that our robot is controlled via Bluetooth. In order to accomplish this task, the BiPed will be equipped with a Bluetooth 4.0 transceiver that will receive commands from the Arxterra application on an iPhone. In this blog post I will be going over the design and test process that took place order to make wireless communication possible.

Custom Commands

The Arxterra application is a robotics iPhone app that was specifically designed to control a robot over Bluetooth. It works by sending packets of data to the BiPed where it will then be decoded to control our system. To ensure our BiPed is receiving the correct data, we must first define our custom commands within the app itself.

Figure 1: Arxterra Remote Control

Our BiPed utilizes 5 basic movements in order to navigate through a maze, they include walking, turning left 90 degrees, turning right 90 degrees, turning left 180 degrees and turning right 180 degrees. Because of this, we must create 5 custom commands to distinguish each function from another.

Within the app, each movement is assigned to a specific command ID. For our BiPed, the assignments are as follows:

Custom Command Command ID
Walk 0x01
Left Turn 0x41
Left 180 0x42
Right Turn 0x43
Right 180 0x44

Once the custom commands are defined, the app is ready to begin transmitting data. In order to actually do anything with these commands, we must now program the BiPed to decode the data packets.

BiPed Firmware

In this section I will go over the BiPed code and how it translates the incoming stream of data.

First we defined variables within the Arduino code that correspond to each command.

Next, within the CommandDecoder subroutine, every command packet the BiPed receives is broken down into individual bytes and read into an array called data.

Then the CommandHandler subroutine is called and assigns the variable cmd to equal the 2nd byte within the data array, this is where the command ID byte is found. Finally using if-else statements, the code is configured to call each movement subroutine based on the Command ID that was sent. This is shown below.

Looking at the code, you can see that I added Serial.print’s before every subroutine is called. This was used during the test phase to ensure the correct subroutine was being called when each command was sent.

Conclusion

After initializing all of the command variables and implementing a series of conditional if-else statements, the BiPed is now able to communicate wirelessly with the Arxterra app.

S17 Prosthetic Arm: Iteration of the Arm Design

This post is about the different problems faced during the design of the prosthetic arm and how they were overcome.

S17 Prosthetic Arm: Servo Rotation Accelerometer Test

This test is conducted to make sure that the wrist will work with the accelerometer in order to activate rotation only when it is in the correct position.

S17 Prosthetic Arm: Temperature Sensor Waveform Input Test

For this test, we are checking to make sure that we can record the temperature input as a waveform and use that information to employ the safety mechanism of powering down the PCB if any of the components get too hot.

S17 Prosthetic Arm: Sleep ISR Test with Analog Sensor

The Sleep ISR Test is done to make sure that once it sees a fluctuation in an analog signal, not unlike a temperature sensing heat breaching 50 degrees celcius, it will power down the MCU and the reduced current draw will cool down the PCB and all of her components.

S17 Prosthetic Arm: Finite State Machine Servo Test

The purpose of this test is to make sure our code can rotate the servo in the wrist of the prosthetic arm only when the EMG sensor detects muscle contraction.

S17 Prosthetic Arm: Buck Converter LTSPICE Simulation

To test if the buck converter we have designed is able to be used to step-down the voltage of the battery at 11.1V to the voltage needed to power the servos, at 5V, safely.