By Marena William (Manufacturing Engineer)
Following the modifications done to minimize the size of the PCB, a new design in SolidWorks was done to reflect the changes in dimensions. The new design does not only show a change in dimensions, but it also illustrates how we overcame the electrodes’ wiring problem without having any wires coming out of the watch housing.
BY: Christopher Hirunthanakorn (Missions, Systems and Test Engineer)
Introduction:
The purpose of this blog post is to summarize the work done on the system design of the 3DoT David and show the final state of the system block diagram and system resource reports. At the end of this blog post, the reader should understand the different subsystems of the 3DoT David, how they interact with each other, and what parts were chosen for each subsystem. The interface definitions matrix is also covered here.
Table of Contents
This system block diagram shows how all of the subsystems of the 3DoT David interact with each other. The major subsystems are the smartphone with ArxRobot App, 3DoT Board, PCB, battery, IR emitter, IR detector, micro motors, gear train, 3D printed legs, and flexible resistors. The interaction between the subsystems will be explained below.
The smartphone with the ArxRobot App is the subsystem that the user will be interfacing with the most. The user will be controlling the movement of the 3DoT David by using the directional pad controls on the app. Those inputs will be sent to the 3DoT Board via bluetooth. It will be processed by the Atmega 32u4 microprocessor that is on the 3DoT Board. If there is any telemetry, it would be sent back to the smartphone but that is not the case for the 3DoT David.
The 3DoT Board interacts with both the PCB and micro motors. It will be sending the control signal for the IR emitter and speaker to the PCB while receiving the outputs of the IR detector and flexible resistors after the processing is done on the PCB. The 3DoT Board also contains the Sparkfun dual motor driver TB6612FNG, which drives the micro motors. The board receives power from the battery.
The PCB contains the Schmitt trigger circuit which converts the analog output of the IR detector into a digital signal for the 3DoT Board to analyze using hysteresis. It also contains the circuitry for powering the IR emitter and speaker. It also contains the voltage follower and antialiasing filters to prepare the outputs from the flexible resistor sensors for the 3DoT Board to process in the motor phase control module of the software.
The IR emitter is controlled by the signal sent from the 3DoT Board and is powered via the circuitry on the PCB. It sends an IR signal in an attempt to tag the opposing robot. Both the IR emitter and IR detector make up the tagging system of the 3DoT David.
The micro motors are controlled by the Sparkfun dual motor driver TB6612FNG and move the gear train of the 3DoT David. The gear train is connected to the 3D printed legs and moves when the gear train moves. The movement of the 3D printed legs will move the entire 3DoT David and is used as the input of the flexible resistor sensors.
This interface definitions matrix shows how the various subsystems will be connected to the pins of the Atmega 32u4 microprocessor. The HC-06 bluetooth module will be connected to pins PD2 and PD3 which corresponds to the TX0 and RD0 pins of the bluetooth module. The Sparkfun dual motor driver TB6612FNG will be connected to pins PD7, PB5, PB6, PC6, PF7, PF6, and PF5, which corresponds to the PWMB, PWMA, AIN2, AIN1, STBY, BIN1, and BIN2 pins. The control signal for the IR emitter is connected to PD1 and that goes to the PCB. The IR detector output is connected to PD0. The speaker is connected to pin PB7.
These are the system resource reports for the 3DoT David. The only major difference since the CDR is that the micro motor has been changed from the 3.7V 50K RPM coreless motor to the 900 RPM Micro Geared Motor.
This power report shows the updated values after changing from the 3.7 V 50K RPM coreless motor to the 900 RPM Micro Geared Motor.
This mass report shows the measured mass of all components used to build the 3DoT David. It can be seen that the measured mass is 62% of the total expected and 50% of the project allocation. This was achieved by using the most efficient design for the 3D printed parts, which reduced the printing time and overall weight of the parts.
This cost report shows both the expected costs for parts that were generated during the PDR and the actual cost of the parts that were selected. All of these prices incorporate the shipping fees for those parts. The total actual price listed is assuming that all of the parts listed will need to be purchased and does not include the cost of the 3DoT Board.
By Marena William (Manufacturing Engineer)
After the group was debriefed on the Critical Design Review (CDR), we realized that our housing dimensions (maximum dimensions) need to be changed. Throughout the course of the semester our goal was to have a fully functional seizure watch however after the PCB layout was done this goal seemed unachievable. This post discusses how we approached this problem.
Read more
By Henry Nguyen (Electronics and Control)
For our Z-Axis actuator, we found that our thread drive will constantly cause our nozzle to shift towards the left when going down and towards the right when going up. This was caused by the two 4mm rods and the thread screw we were using. A slight solution was to attach a rubberband to our nozzle to prevent it from shifting. The following Youtube video shows the problem our nozzle has when going up and down:
https://www.youtube.com/watch?v=Rw_LVb8K-G4
We found that in order to prevent this type of error, we had to have a completely new design for our Z-Axis actuator.
We found a cheap linear slide actuator as shown in the title picture on eBay. After purchasing this sliding unit, we found that the slide will be sturdy enough to attach our A-Axis stepper motor as well as keeping the nozzle in a linear fashion. I needed to design a new bracket that will screw into the sliding unit as well as attaching to our red nut on the lead screw.
Figure 1. Linear Slide Bracket Sketch
For my bracket design, I would attach the linear sliding unit to the top of my bracket with the four holes. The red nut will go through the large circle in the middle. The two screws on the bottom will allow us to attach our A-Axis stepper motor bracket. The last screw hole on top of the A-Axis stepper motor bracket will allow us to screw into the red nut. This will keep the red nut in place and allow us to move the hole unit up and down.
Figure 2. Linear Slide Actuator Bracket
For the bracket, I had to apply some silicone to the red nut in order for it to stay in place. The screw did help to keep it in place; however, I wanted to make sure the red nut is completely stationary.
Figure 3. Full View of Linear Slide Actuator
Figure 4. Side View of Linear Slide Actuator
I uploaded a Youtube video showing the linear slide actuator in action.
https://www.youtube.com/watch?v=UqnxF44cEr8
Overall, this linear slide actuator is a success. It completely eliminated all wobbling caused from our old thread drive kit from Makeblock. We are able to go up and down smoothly as shown in the Youtube link above. This will allow us to rerun all of our accuracy tests to ensure that we are as accurate as possible when picking up surface mount components.
BY: Christopher Hirunthanakorn (Missions, Systems and Test Engineer)
Introduction:
The purpose of this blog post is to summarize all of the work that has been done for the software design of the 3DoT David and inform the reader of the final state of the software. It will cover the software flow chart to introduce the tasks the software has to accomplish and then explain the different modules in the software block diagram. Finally, a brief overview of how each module works in the final version of the code will be provided.
Related Level 2 Requirement:
Table of Contents
The software flow chart shown here shows what the modified Arxterra firmware that will be programmed to the 3DoT board will do. The program will start by initializing all pins and variables used such as the pins for the Sparkfun Dual Motor Driver TB6612FNG, the IR emitter, IR detector, and speaker. Next, it will check to see if a command is sent via bluetooth from the ArxRobot App. If a command was sent, the commandDecoder and commandHandler functions will be executed and the action related to the command sent will be done. When no command is detected, the program will check if the IR detector has registered a tag from an opposing robot. If it is tagged, a sound will be made and the tag counter will be incremented. When the tag counter reaches three, a song will play, the robot will be disabled for 10 seconds, and the tag counter will reset before the loop continues. If there was no tag detected, the program will send any telemetry data that is required. Currently, there was no requirement for the 3DoT David to send any telemetry back to the ArxRobot App.
The software block diagram shown here explains what the different modules do and the types of inputs/outputs of each module. The modules are the commandDecoder, commandHandler, Move Robot, Motor Phase Control, IR Emitter On, Tag Tracker, Robot Disabled, and Telemetry.
For the commandDecoder module, the input is the command data that comes from the ArxRobot App through bluetooth. This data is sent one byte at a time and the commandDecoder module saves this data into an array. Once the entire array is received, this module verifies that all of the data was sent correctly using a state machine and that the command ID matches one of the defined commands. It outputs this array for other modules to use.
For the commandHandler module, the input is the data array containing the command information sent from the ArxRobot App. This module will check the command ID from the array and then execute the corresponding functions for that command. Those functions must be defined individually. If there are any custom commands that need to be added, a corresponding if statement is required to modify the commandHandler module to handle that command ID. There are no outputs from this module.
For the Move Robot Module, the input is the command data that comes from the ArxRobot App through bluetooth. This module includes all of the functions required to move the 3DoT David and is only executed when the move command is sent from the app. It uses the functions defined in the sparkfun_TB6612FNG.ino file and a custom function that operates the motors based on the direction of the move command that was sent. The outputs of this module are the control signals for the Sparkfun dual motor driver and the PWM values for the motor speed, which are designated as digital pins PB5, PB6, PC6, PD7, PF5, PF6, and PF7.
For the Motor Phase Control module, the inputs are the current outputs from the flexible resistor sensors. This module processes those inputs using the code that was provided by the Electronics & Control Division Manager Jeffery Cool. It will compare the two inputs and determine if one of the motors is moving faster than the other. This works because the two inputs will be equal if the motors are in phase. The module will make the two motors in phase by changing the speed of the motors. The output of this module are the PWM values for the motors.
This module was tested and had a slight improvement to the movement of the 3DoT David but it was determined that it was not necessary. It is not implemented in the final version of the firmware because of the limited number of pins that are readily available on the 3DoT Board.
For the IR Emitter On module, there are no inputs. It will only be called by the commandHandler module when the correct command is received. The purpose of this module is to send the command signal to turn on the IR emitter and attempt to tag the opposing robot. It is not always on and will only be turned on when the correct command is received. The module outputs the control signal to the digital pin PD1.
For the Tag Tracker module, the input is the current output from the IR detector. If the signal that is being detected at the digital pin PD0 is low, that means a tag has not been detected. When the signal is high, this module will increment the tag counter which starts at zero. After the tag counter reaches three, this module will call the Robot Disabled module and then reset the tag counter to zero. This module will also create a 5 second delay before it checks the output from the IR detector to prevent consecutive tags. There are no outputs from this module.
For the Robot Disabled module, there are no inputs. When it is called by the tag tracker module, this module will prevent the robot from responding to any commands for 10 seconds and play a short song to indicate that the 3DoT David is disabled. There are no outputs from this module.
For the Telemetry module, the inputs will vary depending on what type of telemetry needs to be sent back to the ArxRobot App. This module will collect the current values from the sensors on the robot and send that information back to the app. It should be called at a maximum frequency of 1 Hz in order to prevent data overload. The output of this module will be a data array that is sent via bluetooth. For the 3DoT David, there was no telemetry that was required.
For the Move Robot module, the existing code was designed for operating a rover and needed to be modified to fit our robot’s movement system. With the new movement system design, both motors will need to be controlled at the same time in order to move because each motor is driving one set of three legs. Additionally, the smoothest movement of the legs required the PWM value to be set to the maximum of 255. If it was any less, the motion of the 3DoT David would look very slow and feel weird. Because of the way the ArxRobot App is set up, the user has to press and hold the direction button to increase the speed of the motors to move in that direction. The code was changed so that the PWM value would be a constant 255 and that the leg movements would be fluid.
For the IR Emitter On module, it was decided that the IR emitter will be turned on whenever the 3DoT David is moving and is off the rest of the time. This is because the ArxRobot App can only send one command at a time and the alternative method of controlling the IR emitter would be using a slider on the app to turn it on or off. Implementing this in the code was easily done by incorporating the command into section of the commandHandler function that executed the move commands.
For the Tag Tracker and Robot Disabled modules, code was added to the main loop to check the output of the IR detector and if the 3DoT David should be disabled. The code is executed after the commandHandler function is called and checks if the robot has been tagged. If so, a counter would be incremented and if that counter reaches three, the robot will be disabled. When hit, the speaker will make a sound and the robot will not check for tags for 5 seconds. When the robot is disabled, it will not respond to any commands for 10 seconds and play a short song to indicate this change. All of this is done by using a flag variable to keep track of whether or not a tag has occurred. The flag will be cleared after 5 seconds have passed. When this has happened three times, the code will enter a loop that keeps it from responding to commands for 10 seconds.
Additionally, all of the extraneous code that was a part of the latest version of the arxterra firmware was removed. This includes all of the telemetry and sensor definitions that were left over from older projects that are not being used for the 3DoT David. All of the code used for debugging and testing were also removed or commented out to make sure additional processing time was not being used up. Comments were also added to help future students understand how the code functions.
The final version of the Arxterra Firmware (click here)
Posted by: Luis Valdivia (Project Manager)
Written by: Anthony Becerril (Mission, Systems, and Test Engineer)
This blogpost will cover the debrief to our group after presenting out Critical Design Review. Next to every topic is the grade received along with feedback from our instructor and division managers. Click here to access our Critical Design Review.
Table of contents:
-Title
-Exec. Summary
-System Design
-Experimental Results
-Interface Definition
-Connection Wiring Diagram
-Custom PCB
-Hardware Design
-Software Design
-Verification and Validation
-Project Update
-Demonstration
Project Update/Review:
Christopher Andelin (Project Manager)
Mario Ramirez (Systems Engineer)
Qui Du (Manufacturing Engineer)
Andrew Laqui (Electronics and Controls Engineer)
Henry Ruff (Electronics and Controls Engineer)
Table of Contents
Qui Du (Manufacturing Engineer)
In Mechanical Design Rev2, https://www.arxterra.com/spring-2016-rofi-mechanical-design-rev-2/ RoFi’s head contains both the PCB and Arduino Mega.
I redesign the head to contain the PCB because my team implemented the Arduino Mega chip onto the PCB board. I also, changed to a smaller size screw for the head from M3 to M2. Since the size of the head covers is 5mm thick, having smaller screw holes give the frame more strength and they make the head look cleaner. Weight is also important therefore, I made the head as light as possible by carving holes, curving parts, and made some parts thinner.
Figure 1: Head Update
Figure 2: Exploded View
Some of the servos come loose because they slide into the frame and do not attach to the frame; to fix this problem, I designed servo locks to lock the loose servos into place.
Figure 3: Loose Servo
Figure 4: Servo Lock
My new mechanical design has a mass of 1651.51 g which is below the mass report allocation of 1745 g found here, https://www.arxterra.com/spring-2016-rofi-preliminary-project-plan/. We prefer lower mass because our current mass in conjunction with our low quality servos, RoFi tends to spasm which causes RoFi to fall over.
Figure 5: Mass Report of RoFi’s Frame
Figure 6: Components Mass Report
Figure 7: Part Name Label
Note: The Arxterra Logo is just for decoration and will not be on the final product.
Figure 8: Bonus RoFi Design
All SolidWorks 3D modeling parts and assembly can be found here, Google Dive Link
Disclaimer: All parts were created in SolidWorks 2016; older versions of SolidWorks might not open the files. I included the STL files to allow students with older version of SolidWorks to view or print parts.
By Chelsea Mediavilla (Electronics and Control)
This trade-off study compares the performance and features of two microcontrollers. The cost, power and communicative capabilities of each MCU is considered.
By Chelsea Mediavilla (Electronics and Control)
In this post, the electronic design of the final printed circuit board is discussed. The Fritzing Diagram, breadboard prototype and Eagle schematic are summarized.
By Chelsea Mediavilla (Electronics and Control)
I discuss the software design for the two main electronics on the CubeSat. The Arduino code controlling both components is explained and provided.
