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
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.
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.
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.
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.
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
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.
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.
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.
<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 \>
Drawings, Schematics, Flow Charts, Simulations
We made quite a few different changes in the design, including:
- Using store bought wheels, instead of creating it on our own.
- No direct application of motor to wheels, instead utilize a belt drive.
- Placement of parts.
- Venting holes.
- Change of specific parts which we were planning on using.
- Creating Electric Wire channels.
- Removing mass to be under needed mass.
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.
Test PlansBelow 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.
Design and Flowcharts
ControllerAfter 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.
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
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).
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.
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.
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.
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.
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.
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.
- Purchase chassis stock and remaining materials
- Machine all components over intersession (40 hours)
- Assemble and test fit of components (8 hours)
- Start testing control of final bot (40 hours)
- Finish purchasing parts for Final Bot. (2 hours)
- Once stock comes in begin machining. (15 hours)
- Begin assembly of final bot over break. (40 hours)
- Look for location to test bot. (4 hours)
- Improve Unity3D Simulation
- Assist in Coding
- Finalize Control Scheme for RC Controller
- Implement XBox Controller Method (Post-Competition)
- Create Smaller Robot (Post-Competition)
- Continue prototyping process ensuring that all subsystems work together. (7 hours)
- 3D print shock absorber, test how it is works. (8 hours)
- As materials start to come along begin machining and building bot. (10hrs)
- Begin assembling subassemblies. (4 hours)
- Plan for MSDII - Motorama and Imagine RIT. (8 hours)
- Complete Second Bot Prototype
- Write Magnetometer Firmware for Interrupt-Based Interface
- Modify Custom App for BLDC Motor Controllers
- Work on LED POV display control
- Work on Embedded Version of Control Scheme
|Stephen Pasek||Jimmy Kramer||Alex Howard||Rob Sokolowski||Jacob Harrell|