During our system design phase we focused on both the mechanical and electrical side of our physical design as well as reaching out for funding. First, we will look at the mechanical side of the system design phase. The three Mechanical Engineering students, Stephen, Jimmy, and Rob, each designed multiple robot prototypes to allow for individual creativity and thought. After the first set of designs were made we went over each design to begin bouncing ideas off each other. We then went back on our own to come up with new designs. Now our designs were starting to have multiple similarities and this is when a final design began to be worked on.
Next, we will look at what the Electrical side Jacob and Alex, had been working on during this phase. They began planning the logic for our robot knowing the engineering and customer requirements. This was being done while they began researching what components would be used for our robot. Due to the RPM our robot would be spinning at they were challenged with finding components that could take in the information at a fast enough sample rate and not be interfered with the magnetic fields created.
We also began planning a test bed that would allow us to test our electric components before our robot was built to see how the magnetic fields would affect the components ,as well as, being able to have our components spin at known RPMs to make sure the data received was correct. Overall, we stayed very busy and kept to our tight schedule.
System Level Design Documents: Systems Level Design Documents
Team Vision for System-Level Design Phase
As a team we set very high expectations of what we wanted to get done during this phase. This was due to our competition date being so early in the second semester. We had several goals that were met during this phase. The first being beginning to work on our final design, the second being starting to outline the logic for our electrical components, and the third coming up with a design for our test bed. These are all very important steps that were crucial to have done at the end of this phase, so our project did not fall behind.
- A translational drift robot for a BattleBot style Competition.
- Durable and modular for easy repairs.
- Accuracy in determining heading.
- Stable when stationary
- Use of absolute reference relative to the Earth's magnetic poles and operators orientation.
- Complies with all NERC regulations.
Matlab code was used to determine motor requirements. The code used the rough mass properties of the robot (mass, Moment of Inertia, drive dimensions) and output the rotational speed of the robot and motor speed at half power and full power and the motor torque required for spin up. Once the motor requirements were set, we selected a few motors from the benchmarking table and ran them through a spreadsheet that produced a more detailed analysis of the robots spin up. The spreadsheet output a graph of the rotational speed and energy of the robot as a function of time and also gave us the necessary power requirements based on the motors electrical properties.
Feasibility: Prototyping, Analysis, Simulation
Total project cost poses a major risk to project success.
Above is our current bill of material (BOM). We have begun purchasing parts off of this BOM so we can begin testing. This BOM also serves as justification for the additional funding needed from the Simone Innovation Center. For the most up to date BOM click here.
The measurement range of the accelerometers, sample frequency of the magnetometer, and sensor tolerance to high impact acceleration pose a major risk to the project. A series of tests must to be run to validate the sensor functionality.
The sensors and motors will be characterized separately and then concurrently to validate proposed functionality under parasitic effects.
This test rig was developed to test the sensors under high rotational velocity. For further tests, a feedback loop-based control will be used to vary the disk speed, however the controllable drive can only reach 900rpm while the open-loop drive can reach speeds of up to 2500rpm. The Arduino is used as a tachometer, outputting the disk's rotational period.
Morphological Chart and Concept Selection
|Melty Brain - Baseline||0||0||0||0||0||0|
|Concept||Easy to Use||Cheap||Variable Input||Easy to Make||Ergonomic||Intuitive||Total|
|RC Controller - Baseline||0||0||0||0||0||0||0|
|Pre-Built Traditional RC Controller||s||s||-||+||s||-||-1|
|Modified Pre-Built Gamepad||+||+||+||s||+||+||+4|
Below are snapshots of our current CAD design incorporating our specific requirements, while also choosing the optimal design with the least amount of cons.
After further discussion we decided to create our own wheels and hub assembly so that we would be able to attach them straight to the motor since it has a spinning canister.
Systems ArchitectureBelow is a flowchart diagram describing how the transnational drift bot will function in a typical competition, detailing possible ways which it will be affected by the opposing team.
In the following Section of Designs and Flowcharts we describe exactly how the bot will be interacting both electrically as well as what information and controls it will be receiving and transmitting
Designs and Flowcharts
While waiting for instructions, the robot samples the accelerometers on a regular period, then uses the samples, combined with the time since the last sample, to calculate how far the robot has turned, giving an estimated heading. The IMU operates on a much lower frequency, so it will be sample more infrequently. Once it is sampled, the reading is error corrected with the estimated heading to produce an error corrected estimate. Based on the mode configuration, either the error corrected estimate or the base estimate are then used with the values of the inputs from the decoded instructions to determine the PWM at which each motor should be operating at. These PWMs are stored to variables.
On a separate interrupt, these stored PWMs are used with the current PWMs to create smooth transitions in the motor speeds using PID.
Risk AssessmentDuring this phase we realized that we would need additional funding beyond what the MSD class provided. Being a project that was created by an individual student there is no additional funding provided currently. Therefore, we reached out to the Simone Center at RIT to seek additional funding. The funding was necessary because the projected cost was over $2,500.
After reassessing our risks, we determined that our top risks are still sponsorship, and our fast-paced timeline. Out of these two risks obtaining sponsorship is clearly the bigger of the two since ultimately without enough funding we will be unable to create a bot in the desired featherweight weight class. With the February 17th deadline approaching we are eager to begin prototyping individual systems and prototyping the system as a whole.
We have been actively in contact with the Simone Center for Innovation and Entrepreneurship to receive sponsorship and begin in testing the subsystems as parts start to come in.
Alternative ideas if we do not receive sponsorship have been discussed, and are included in the list below:
- Create a translational drift bot specifically for Imagine RIT.
- Go to a lower weight class decreasing the cost.
- Attempt to find additional funding to maintain the weight class.
If funding is not received the last choice, finding additional funding is the preferred option, although with the timeline it might be an obtain funding and meet the deadline.
To address the issue of our rapid timeline we are trying to be ahead of schedule and get our design completely fleshed out, so when parts start coming in we will be able to incorporate them immediately.
For the latest Risk Assessment click here.
Design Review Materials
Plans for next phase
Below are what everyone is planning to be working on in the following 3 weeks.
- Design robot chassis to fit all components.
- Participate with team on creating final BOM.
- Source components for robot drive system: motors, battery, etc.
- Assist teammate with wiring diagram to learn more about the controls.
- Test sensors
- Work with Stephen and Rob to complete the Final Design of our Robot.
- Begin designing and constructing molds for our wheel and hub design.
- Begin ordering parts to build our robot.
- Once stock has been bought I will work with Stephen and Rob to begin machining our bot’s body.
- Refine our design once we see issues with either assembly or machining.
- Refine Software Flowchart for Controller and Robot
- Create Software Pseudocode for Controller and Robot
- Begin Testing Sensor behavior and creating prototype algorithms and software (with Jake)
- Select final Microcontrollers for Controller and Robot (with Jake)
- Refine Connections diagram to Microcontrollers (with Jake)
- Refine Wiring Diagram (with Jake)
- Decide on from-scratch gamepad or modified gamepad Controller
- Fully enter prototyping phase of robot design (with Jake)
- Select transmitter/receiver encoding methodology (with Jake)
- 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.
- Continue meeting with Simone Center for Innovation and Entrepreneurship to discuss sponsorship.
- Design a prototype bot, utilizing a 3D printed frame to represent our Aluminum Chassis.
- Order, receive and test motors, if time allows.
- Begin purchasing of mechanical parts for the prototype and final bot.
- Simulate the movement of the robot based on the expected control scheme
- Calibrate the accelerometers and magnetometer using the test rig
- Refine hardware layout depending upon chosen microcontroller and sensors and communication.
- Order parts for electronics prototyping (Microcontroller, Batteries, Possibly motor controllers, Radio Tx/Rx, etc.)
- Refine Test Rig control topology.
|Stephen Pasek||Jimmy Kramer||Alex Howard||Rob Sokolowski||Jacob Harrell|