P18390: Translational Drift Robot
/public/

Detailed Design

Table of Contents

Content related to the Detailed Design review are located here.

Team Vision for Detailed Design Phase

During this phase we wanted to finalize our design, create a final Bill of Materials(BOM), and begin to order parts for both our test bot and final bot. On the mechanical side we wanted to have our final CAD finalized, mainly the placement of every part and the design of each sub-assembly to be fleshed out. On the electrical side we wanted to ensure that each connection was correct and would allow our bot to work well. On the software side we wanted to begin the code and have a preliminary design with simulations to see how our bot would be receiving commands and responding. In addition, we wanted to begin creating and assembling a prototype to begin testing out our robot. In general we wanted to clear out some of our high risks, which was mainly registering for Motorama.

During this phase we were able to accomplish the tasks which we had set out to accomplish. After a couple iterations of the design we were able to find the best location for each part, while also creating shock absorbers. Electrically we determined that we would not be using the separate 9V battery and would be drawing power from the LiPo battery only. In addition, we were able to set up the test bot using test motors to begin making the robot work. In terms of software we began looking into the code and created a simulation to see how the transnational drift bot would work. Lastly we purchased more parts from various suppliers for the final bot. We only have a couple more parts to purchase and then we will have all the materials necessary to begin construction of the final bot.

Compared to our preliminary design we made quite a few changes leading to a better functioning design which will be more suited for our upcoming competition(Motorama). In the following sections we will discuss the differences and justify why we made certain decisions.

Prototyping, Engineering Analysis, Simulation

BLDC Motor Wiring

BLDC Motor Wiring

This shows the wiring for the BLDC motor controller, In this configuration, the controller is connected via USB to a computer. in the final build UART or analog voltage will be used for speed control.

BLDC Motor control software

BLDC Motor control software

The BLDC tool is an open source program developed for usage with the VESC (otherwise known as the SK8-ESC). The program allows the ESC's to be reconfigured based on the specific motor used.

BLDC Motor Control

BLDC Motor Control

This short clip shows the BLDC motor controlled without Hall sensor feedback. Based on these results a higher voltage battery (6 cell) is needed for the final robot. Additionally, the motors will not directly drive the wheels to avoid voltage spikes due to sudden torques.

BLDC Motor Reversibility

BLDC Motor Reversibility

In this clip the BLDC motor is driven at low speed ~1000rpm. Partway through the clip, the motor direction is reversed by sending a negative value for RPM. This demonstrates that the motor can successfully be controlled using the SK8-ESCs in both forwards and reverse directions, contrary to distributor specifications.

Controller to be Used for Final Design

Controller to be Used for Final Design

This was the controller sent to the team by Austin McChord. The receivers it is paired with work on a serial bus protocol compatible with the teensy3.2. The firmware used to receive the controller data can be found here

Sample of Received Throttle Signal

Sample of Received Throttle Signal

The throttle channel was sent via simulated serial to a serial plotter. This image shows an example of the throttle being turned up for a short period of time.

Sample of Received Trim Signal

Sample of Received Trim Signal

The trim channel was sent via simulated serial to a serial plotter. This image shows an example of the directional trim being adjusted. The small high frequency noise on the signal should be noted as it may be necessary to filter out small, high frequency changes so as to avoid unintended operation.

Sample of Received Forward/Reverse Signal

Sample of Received Forward/Reverse Signal

This shows an example of the forward, reverse channel received data. the high frequency oscillations are from the joystick springing back to the center. Signals similar to this may need to be software filtered to avoid unexpected behavior.

First System Prototype

First System Prototype

This was the first prototype of the full system. At first there were issues with communication since a 9 volt battery was used to power the receiver, micro-controller and the sensors via a buck converter, In this case the battery was unable to source enough current to run the receiver. To solve this issue, the buck converter was connected to the main lithium polymer battery. The DC motors used also proved to be too slow to implement Meltybrain style control. These issues will be remedied by switching to the BLDC motors and SK8-ESC motor controllers donated by Austin.

<br \> In addition, a software simulation of the robot was begun in the Unity3D engine, a screenshot of the test is shown in the image below. The simulation creates mock forces which rotate and move the robot. <br \>

Screenshot of Unity3D Simulation

Screenshot of Unity3D Simulation

Drawings, Schematics, Flow Charts, Simulations

We made quite a few different changes in the design, including:

Isometric View of Design: Showing Belt driven system

Isometric View of Design: Showing Belt driven system

Mass properties of Design

Mass properties of Design

Wheelbase Distance

Wheelbase Distance

For an up to date Drawing Package detailing the dimension and drawings for both assemblies and individual parts click here

Bill of Material (BOM)

Below we have our Final BOM. We are currently sitting around $1500. This is below our current budget of $2000, $500 from MSD and $1500 from The Simone Center. We have also received many electrical components from a sponsor that will lower our overall expense as well which is not accounted for here. We are pleased to see this because previously our budget was our number one risk.

Final BOM as of 12/7/17

Final BOM as of 12/7/17

Google Drive of up-to-date Final BOM

Test Plans

Below is our continued Test Plan that we are currently in the process of. We have plans over the winter break to get as much of these tasks done in preparation for our competition in February. As of now we are very confident all of these objectives will be accomplished in time for our Final Bot to be built and ready for competition.
Updated Test Plan

Updated Test Plan

Design and Flowcharts

Updated Designs

Controller

After speaking with Austin we decided to utilize a regular 2.4 GHz radio frequency signal for the competition since you can not afford there to be any errors. The reason for this being that we need to ensure we will be ready for each battle as fast as possible, leading us to not have the luxury of taking our time for setup since it could cause us to forfeit the match and ultimately not do as well as wanted. In addition to this we will be changing our design to run on a general melty brain model, without having a heading based on the users position. This being for the same reason since the setup would take too long for the competition. This lead us to the hard decision of ensuring our possibility to compete, compared to meeting our engineering requirement before the competition. At the same time, using a prebuilt RC controller simplifies our software requirements immensely, reducing the controller software to absolutely nothing. This results in the flowchart below, where the controller automatically transmits instructions.
RC Controller Flowchart

RC Controller Flowchart

In terms of Imagine RIT we still plan to develop the technology of controlling it based on the user position, allowing for a more intuitive experience. We plan on using a pre-built, wired XBox 360 controller interfacing with a Raspberry Pi to control the robot, rather than a completely from-scratch design, as explained earlier. Plenty of Sources online provide examples of doing something similar, so examples are available for us to work from.

Controller Mapping : Key - 1:Deadman Button 2:Change Modes 3:Adjust Robot's Rotational Speed 4:Adjust Rotational Trim Up 5:Adjust Rotational Trim down 6:Adjust Translational Trim 7:Move Robot

Controller Mapping : Key - 1:Deadman Button 2:Change Modes 3:Adjust Robot's Rotational Speed 4:Adjust Rotational Trim Up 5:Adjust Rotational Trim down 6:Adjust Translational Trim 7:Move Robot

Controller Mapping : Key - 1:Throttle 2:Translation 3:Trim

Controller Mapping : Key - 1:Throttle 2:Translation 3:Trim

The Image above shows a proposed control scheme for the XBox Controller. Several of the controls are unused. Most control schemes will likely stay close to this design. The only controls that may change are the rotational trim buttons (which may not be necessary), and the Deadman and Mode Change buttons (which may change to any of X, Y, A, or B, depending on which is easier for the user).

Controller Software Flowchart

Controller Software Flowchart

The flowchart above shows the software flow of the controller. If possible, the Raspberry Pi will listen for a press of the Mode Change button and flip the robot mode between two states: Absolute Reference and Local Reference. The Pi will also listen for presses of the trim buttons and adjust local variables. Transmission will depend entirely on the IMU reading, as that will most likely be the slowest input to read from. Once the IMU is ready, the Pi will read from it; read the Trigger, Joystick, and Deadman Button Inputs; and then it will calculate and encode the appropriate instructions, adjusting for trim on board. Trim adjustment is done on the PI to save on transmission space and calculation time on the robot. This may be unnecessary. This will happen if the mode is Absolute. If the mode is local, the Pi won't bother waiting for the IMU and will calculate and encode instructions as fast as the transmitter will allow it.

Robot

On Instructions Received

On Instructions Received

The flowchart above shows the simple process performed when the robot receives new instructions. It will decode the instructions down to their base components: Mode, Transnational Vector, and Rotational Vector. These components will be stored to variables for use by other software segments.

Estimation of Headings

Estimation of Headings

The flowchart above shows the flow of heading estimation from Accelerometer and IMU to estimated heading. Based on preliminary prototyping, we know that the accelerometer will require some form of smoothing, and the current plan is to use software smoothing, though hardware smoothing is not out of the question at this point. the IMU may require smoothing as well, but we will need to perform additional testing before that becomes clear.

The accelerometer estimations will occur regardless of the mode the robot is in, and will happen as fast as they possibly can. The IMU will update at a slower rate, and will serve as the bottleneck. As soon as a reading is ready, it will be used to create an error corrected estimate with the accelerometer estimate. Both estimations will be saved to local variables for use by the PWM calculation process. Once the appropriate estimation is ready, it will trigger an interrupt that leads to the PWM calculation process and the Persistence of Vision Process.

Calculating Motor PWM

Calculating Motor PWM

Adjusting Motor PWM

Adjusting Motor PWM

The two flowcharts above and to the right show the flow of reading the desired translation and rotational speed (from the received instructions), as well as the current heading estimation, to calculate the desired PWM of the motors. This value is stored in a local variable to be read on a repeated interrupt. In this interrupt, the current PWMs of the motors is read and compared to the desired PWMs. Using PID to create a smooth transition between speeds, the current motor PWMs are then adjusted.

Persistence of Vision Display

Persistence of Vision Display

The flowchart above shows the flow of using the current estimated heading and lighting some combination of six LEDs to create a Persistence of Vision (POV) display. The POV display is primarily used for the local reference mode, but will also be used for debugging and potentially displaying an image for the absolute reference mode. There will be three LEDs on the top and bottom of the robot (to account for the robot flipping over). This means that there will be three set/clear signals with two LEDs per signal.

Risk Assessment

Risk Assessment Snapshot

Risk Assessment Snapshot

For the most up to date file reference here.

Looking at the risk assessment we can see that there was an increase in equipment failure, funding and scheduling. The equipment failure likelihood increased since we had a increase in the amount of components which we are utilizing. To fix this we are maintaining a modular design with a newly designed shock absorber for impact resistance. Additionally, we plan to have backup parts so that we can replace the parts if anything breaks. Depending on scheduling we may see difficulties meeting, for this we plan to create a schedule and follow it as closely as possible to ensure when we are able to meet we will be effective. The third risk which grew is that we currently are unable to access the funding from Simone Center for Innovation and Entrepreneurship. Although we will will be able to utilize that funding and be able to buy the rest of the needed material.

Risks which have lessened is the subsystem integration, since we have been working on our prototype and it has the meshing of each subsystem has been coming along nicely. This being said we still do have quite a few aspects to address before it is fully functional. Also we are registered for Motorama meaning that risk has been eliminated.

Design Review Materials

For our agenda click here

Plans for next phase

Below are what everyone is planning to be working on in the following phase.

Stephen Pasek

Jimmy Kramer

Alex Howard

Rob Sokolowski

Jacob Harrell

Individual Three Week Plans
Stephen Pasek Jimmy Kramer Alex Howard Rob Sokolowski Jacob Harrell

Home | Planning & Execution | Imagine RIT

Problem Definition | Systems Design | Preliminary Detailed Design | Detailed Design

Build & Test Prep | Subsystem Build & Test | Integrated System Build & Test | Customer Handoff & Final Project Documentation