Preliminary Detailed Design
Content related to our Detailed Design review can be accessed here.
Team Vision for Preliminary Detailed Design PhaseDuring this phase, our team focused on acquiring the electronics we wished to test and incorporating them into the test rig as well as developing the CAD model of the bot more. We have all the sensors we need and are only waiting on the transmitter and receiver so we can get data back from tests. Our CAD model is close to completion, with just electronics mounting and wheel mounting plates remaining. We were also able to acquire additional funding from the Simone Center. For the next phase we will get more data from testing and use that to write the control software. We will also begin designing a controller for the bot. The CAD model will be completed by the end of next phase and we will be ordering stock, so we can begin manufacturing our bot. We will also create a test bot to test our software controls while waiting for the full bot to be completed.
Prototyping, Engineering Analysis, Simulation
Initial prototype for accelerometer and microcontroller circuit design. More detailed data will be availible when the Transmitter/Receiver Pair arrives.
Currently the LED's change brightness proportionally to the accelerometer outputs.
Feasibility: Prototyping, Analysis, Simulation
Accelerometer data was gathered for low acceleration. At low acceleration, some offset,error and non linearity can be observed. Higher velocity data will confirm this when the transmitter/receiver pair arrives.
The longer LED paths (inner path) indicate positive acceleration, while the sorter paths (outer ring) indicate negative acceleration. This demonstrates preliminary functionality of the accelerometers. More testing will be needed using the transmitter/receiver to confirm results and gather more data.
Drawings, Schematics, Flow Charts, SimulationsYour team should have completed a significant portion of your detailed design, but it will likely require revision based on feedback at your design review.
Below are the elements required to build and operate the entire system, mechanically showing how each subsystem will be linked together and how each subsystem will work individually. Electronically we see schematics showing how the robot will be wired. In terms of software we see the process and flow of how to robot will interact and preform.
For link to our images please click the link below.
Bill of Material (BOM)
PurposeConfirm that all expenses and contingencies are afforded by the project financial allocation
Each robot subsystem requires its own set of test procedures, as well as test procedures for the full robot
Properties for the polyurethane can be found here.
The procedure for casting wheels is quite simple, including just 3D printing the mold, then pouring the polyurethane and waiting until if is fully cast. After we create at least one set of wheels we want to test their durometer, as well as the life cycle of each. To obtain the durometer hardness we will conduct ASTM D2240, with the following procedure on a 1/4 inch specimen.
- Place the specimen on a hard flat surface.
- The indentor for the instrument is then pressed into the specimen making sure that it is parallel to the surface.
- The hardness is read within one second (or as specified by the customer).
To test the life cycle we will spin the wheels on a floor similar to a battle bot arena (concrete or steel) to see if the wheels will ultimately reach failure through loss of adhesion to the hub. In addition this test will allow us to measure how much wear the wheels will experience with a given force (weight of the bot) in addition to constant spinning.
Design and Flowcharts
ControllerIt was decided to use a pre-built, wired XBox 360 controller interfacing with a Raspberry Pi to control the robot, rather than a completely from-scratch design. 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, Translational 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.
Use CaseBelow is a new use case where we are looking at what types of bots we will being going against and the possible dangers that each one offers our bot. There are three types of bots that are most common and offer different types of issues for us to deal with. The first being wedge bots which main issue they pose is the ability to flip us over. We have combated this issue by making our bot invertible in case of this situation. Next we have rammer style bots which could have the threat of causing our internal components to become loose and stop working. The main way around these bots is to avoid direct hits and attack from their other sides. Finally, we will potentially have to deal with clamper style bots. These bots are the least of our concerns as it will be quite difficult for them to grab us do to our short build and wide diameter.
For the most up to date copy click here.
After furthering our design our risk has slightly changed, first by adding specific sub assemblies including a shock absorbed and creating our wheels. Adding these to the design have increased the demand of time which we need to allot into the design and fabrication of the bot. In this circumstances we believe that the added sub assemblies add real value to the overall safety of the components, as well as better control and wear via the wheels since they will reside on the canisters allowing for even distribution, as well as better grip. To ensure that we still finish in time we are going to continue on our rigorous track and add specific intervals in relation to the new systems added.
Also our largest risk, of financing the project has been solved by the Simone Center of Innovation and Entrepreneurship, since we obtained sponsorship of $1500, making our total $2000. This is the greatest option since it allows us to maintain our weight class and participate within the wanted competition.
In regard to the competition we introduced a new risk of not being registered. Registration for Motorama 2018 went live with the first half being filled quite quickly. This means that we are not currently registered for the competition, introducing the added risk. With help from our customer Leanne Chushing we have a plan to obtain a spot at the competition. Leanne suggested that we get our team registered as quickly as possible and contact the admins to let them know that our project is for school, ultimately bumping us up on the waitlist for the second half of the registration.
Design Review Materials
Our agenda for today's preliminary design review can be found here.
Plans for next phase
Below are what everyone is planning to be working on in the following 3 weeks.
- Finish design of robot chassis.
- Participate with team on creating BOM.
- Test our sensors.
- Register for Motorama (11/29/17)!!
- Begin building our test bot.
- Begin Making our Test Battle Bot. (5 hours)
- Continue ordering parts for our robot. (4 hours)
- Once stock has been bought I will work with Stephen and Rob to begin machining our bot’s body. (5 hours)
- 3D print molds for wheels and cast wheels. (5 hours)
- Crash Course in Raspberry Pi
- Test Raspberry Pi and Controller Connection
- Test Transmitter/Reciever and Raspberry Pi
- Control a motor with the XBox Controller and Raspberry Pi
- Design case to attach Raspberry Pi to XBox Controller
- 3D Print designed case to ensure it attaches to controller without issue
- Continue to hone in on a specific design and then create a complete drawing package showcasing each part and the dimensions necessary, exploded view, and GD&T. (7 hours)
- Begin building prototype ensuring that all subsystems work together. (7 hours)
- Begin purchasing of mechanical parts for the prototype and final bot. (4 hours)
- 3D print molds for wheels, cast wheels and test durometer/life cycle. (10 hours)
- 3D print shock absorber, test how it is works. (8 hours)
- Complete Detailed schematic
- Detailed and High speed data for accelerometers and magnetometer
- Continue Prototyping
- Finish ordering Electronics
|Stephen Pasek||Jimmy Kramer||Alex Howard||Rob Sokolowski||Jacob Harrell|