Hardware components | ||||||
 |
| × | 1 | |||
 |
| × | 1 | |||
| × | 1 | ||||
 |
| × | 10 | |||
 |
| × | 1 | |||
Hand tools and fabrication machines | ||||||
 |
| |||||
 |
| |||||
Introduction:
As part of our Applications of Embedded Systems class, we were tasked with coming up with a project that uses the MSP432P401R microcontroller. Naturally, we wanted to play with lasers and robotics! So we came up with the idea of a mobile laser turret that could identify target faces, stop it's scanning motion and toggle a laser to signal it has identified it when within the cameras range of sight.
Laser Quaade:
Project Overview
Project codename “Group Name” is a compilation of multiple different systems in order to build a fully functional Quaade quadruped robot with the ability to recognize targets using a camera/laser system attached to a dual-servo rotating base. The goal was to make Quaade not only have the ability to move freely with wireless onboarding of code but also make a functional mobile turret platform to aim a laser and give visual feedback on targeting and image processing. The applications of adding this technology to Quaade instantly make it possible for many new features to be onboarded such as object recognition and reaction pairs with a few more adjustments with a multitude of various potential A.i. implications.
Project Scope
The overall project is a quadruped robot (Quaade) that moves remotely, can identify targets, and activate a laser to “shoot” the target. The components that move Quaade are 8 servo motors and an MSP432. He is also outfitted with the Raspberry Pi Zero W, a Raspberry Pi HQ Camera Module, and a laser diode. The camera allows Quaade to be able to spot objects and targets for movement through the code on the Raspberry Pi. When Quaade identifies a target in his operating environment he will activate the laser diode and “shoot” the target. The main way Quaade is able to move will be through user-controlled movement through a wired controller. Quaade is able to activate the laser on its own or by user input. A stretch goal for our team will be integrating a hypersonic sensor to give Quaade the ability to move freely and avoid obstacles through the coding on the MSP432. This code tells the servos attached to Quaade’s legs to move when possible and to stop and change direction when forward movement is not possible.
The team building the project has divided the project workload evenly as well as integrated teamwork to allow every individual to have a complete understanding of the project and operations of Quaade. Will F. worked on programming the MSP to allow the user to be able to move Quaade, the camera, and laser to see and “shoot” targets. Mitchell C. worked on programming the camera to allow Quaade to individually identify targets, Ray worked on the circuit design and integrating each component together. We all worked together on the whole project to make sure that all of the components and the programming worked together. This allowed the entire project to be seamlessly integrated into an elegant system that allows the quadruped to interface with Quaade so it moved and “shot” targets.
Functional Block Diagram
This project works around two different processors. The MSP432 is used for controlling Quaade’s legs, the laser turret, and the laser itself. The legs and turret are controlled with Pulse Width Modulation (PWM) signals and the laser is controlled through the use of a transistor. The Raspberry Pi Zero W is used to process images from an attached camera for target identification. It then tells the MSP432 to move the turret left, right, up, or down through UART communication. Because the Raspberry Pi has a wifi processor onboard, it can be used to receive commands from a phone or other electronic device. Figure 1 is our functional block diagram. A 5-volt regulator is used to supply power to all the components.
Wiring Diagram
Within the wiring diagram below, we have our base systems setup with an MSP as the brian, Raspberry Pi Zero W as the center of communication for the camera system, including a power connection to the servo controller.
From the servo controller, we see the ability to control not only Quaade’s four legs (two servos each) but the turret servos as well. A transistor is also necessary with the laser to ensure the MSP will not have too much current drawn through its GPIO pins and two voltage regulators to finish the system and make a standalone robot with the ability to store and utilize power.
Pin Map
The connection between the different modules end up being minimal and not too complicated due to the utilization of communication protocols such as UART and I2C between devices. The device with the most connections ended up being the servo controller since it had to connect to 10 different servos as well as Serial CLock and Serial DAta for I2C.
Schematic for PCB
Our PCB schematic was broken into four separate sections. The first was the laser module. This schematic consists of a transistor to control the current flow of the laser diode and avoid drawing too much current from the MSP. The second schematic is the headers that the MSP slots into as well as zero ohm resistors to select how power is delivered to the MSP. The third schematic is the Raspberry Pi header slot. This also has the zero ohm resistors for power selection. The final schematic is the most complex. It contains three power regulators, one 5 volt, and two 3.3 volt regulators. It also contains the servo controller IC and related components.
PCB Layout
As part of the project requirements, we designed a PCB for our project that would allow easy connections between each of our components as well as the motor driver and power converters built into one package to minimize weight and part count. Due to the shipping and manufacturing time of PCBs we opted to assemble our project on a breadboard to make sure everything worked together by the end of the semester. Below we have pictured a 3D render of our PCB as well as the top layer of our PCB. The three clusters of components are the power regulators and the long and large component is the motor driver. Pin headers are used to attach the MSP and Raspberry Pi in a removable fashion.
Project Requirements
As previously stated, the broad goal of this project to develop a mobile facial recognition platform. A laser is used to visualize accuracy and confirm the presence of a face, a camera will be used for identifying, and two servos will be used for target location and movement control with the turret ceasing rotation when a subject is found. Our most basic requirements for this project include a robotic platform that holds everything, a two-axis turret with a laser and a camera mounted to it, facial recognition software, and an internal power supply. The robotic platform, must be able to carry the rest of the project, and it must be able to move forwards, backward, left, and right. The two-axis laser and camera module must contain both the laser and camera facing in the same direction without much deviation and misalignment, they must also be close in distance so triangulation will not need to be used. The target recognition system will be on the Raspberry Pi and hopefully be easy to implement. Both AI object detection or QR code detection is acceptable. The internal power supply must be able to power the servos, processors, and laser without a dangerous level of power draw.
Debugger (WILL)
The debugger was mainly used in the correction of wrong or incorrectly used macros. Specifically during the development of the receiving end of the serial communication from the Raspberry Pi to the MSP432, I used leveraged code that had incorrect macros that were used to receive the data. The debugger had an error showing for an undefined macro. So in this case instead of using the macro, I set up the pin without the macro to resolve the issue.
- The debugger was mainly used in the correction of wrong or incorrectly used macros. Specifically during the development of the receiving end of the serial communication from the Raspberry Pi to the MSP432, I used leveraged code that had incorrect macros that were used to receive the data. The debugger had an error showing for an undefined macro. So in this case instead of using the macro, I set up the pin without the macro to resolve the issue.
Before:
After:
The other way we refined the code for the movement of quade was the use of physical testing of the servos on the legs. This process went as follows. First, use angles that seem to make sense for the legs to move correctly. Second, load the code onto the MSP432 and see if the quadruped can walk as intended. Third, if the previous angles were not optimized for performance, then change angles and repeat the process.
- The other way we refined the code for the movement of quade was the use of physical testing of the servos on the legs. This process went as follows. First, use angles that seem to make sense for the legs to move correctly. Second, load the code onto the MSP432 and see if the quadruped can walk as intended. Third, if the previous angles were not optimized for performance, then change angles and repeat the process.
The previous type of coding and physically checking was also used for the optimization of the speed of the quadruped’s movements. The speed will be defined as the time between each increment of an angle of a servo implemented by a for loop between each increment. After originally setting a slower movement speed, we checked and rechecked faster and faster speeds till the movement seemed optimized.
- The previous type of coding and physically checking was also used for the optimization of the speed of the quadruped’s movements. The speed will be defined as the time between each increment of an angle of a servo implemented by a for loop between each increment. After originally setting a slower movement speed, we checked and rechecked faster and faster speeds till the movement seemed optimized.
While developing the code for this project, we were given a large amount of the code to use for leverage in our system design. Since this code had already been debugged and tested, the debugger was not as crucial to the testing process as it would normally be for most projects. We did augment the original code to fit the systems specific needs; however, while making changes to the code may cause some errors, in our case the changes made were based on physical attributes of the project and not mainly on the internal structure or dynamic. Therefore, the main testing phase of this project took place in physical optimization testing, and the use of the debugger was minimal.
- While developing the code for this project, we were given a large amount of the code to use for leverage in our system design. Since this code had already been debugged and tested, the debugger was not as crucial to the testing process as it would normally be for most projects. We did augment the original code to fit the systems specific needs; however, while making changes to the code may cause some errors, in our case the changes made were based on physical attributes of the project and not mainly on the internal structure or dynamic. Therefore, the main testing phase of this project took place in physical optimization testing, and the use of the debugger was minimal.
Software Diagram
Code/Github
This initializes the serial ports in regards to the raspberry pi section to implement the sending of a character confirming that a face is identified as someone we have cataloged, (i.e. preset faces/pictures of us).
This code above is the code that runs when a face is found within the frame and loops over them to cross reference back to the function provided using dlib facial recognition libraries. If it matches, it cross references the saved file name given, which in this case is the subject’s name. It then sends an encoded unicode ‘a’ character across the onboard serial port’s GPIO14 and GPIO15 respectively, however GPIO15 is not utilized on the raspberry pi zero W as the code on the MSP does not need to send a signal back.
This screenshot depicts part of our main.c function for the movement for the quadruped. This part of the code seems daunting at first with a ton of for loops, but if you look closer that is what makes it somewhat simple. So each for loop is used to move each servo incrementally in order to control the speed of the movements. This incremental movement is coupled with another nested for loop that allows us to change the delay between each increment to have precise control over the speed. For example, the first 8 lines of code in the image shows all 4 legs moving back 40 degrees as well as having a delay of 500 between each degree moved. The number 500 used in the nested for loop can vary depending on how fast you want the servos to move between each degree increment, and the 40 degrees in the main for loop on the first line of the image can also be changed based on the specific servo position. The rest of the code shows the servos moving in such a way that the robot will move: 1) all legs back 2) left leg forward 3) right leg forward 4) all legs back 5) right leg up 6) right arm up and repeat.
Work Break Down
When taking a look at the project and splitting the tasks up we are dividing it into three areas of specialty to make it essentially three separate mini-projects that fit together for a working system. The three different sections of the robot are as follows:
QUAADE SERVOS/LEGS (MSP): Will F.
TARGETING SYSTEM (RASPBERRY PI): Mitchell C.
TURRET SERVOS + LASER POSITION: Ray R.
There is also a full-resolution live spreadsheet with the project steps/assignments planned out found at this link here.
Trade Study
What type of camera should we use?
What field of view should we use?
- What field of view should we use?
A wide-angle would allow for camera mounting on Quaade’s body and not on the turret, alternatively, mounting to the turret makes up for a less wide angle in mobility.
- A wide-angle would allow for camera mounting on Quaade’s body and not on the turret, alternatively, mounting to the turret makes up for a less wide angle in mobility.
A smaller field of view would give us a greater resolution and allow for a greater target identification range, but the camera would have to be mounted on the turret.
- A smaller field of view would give us a greater resolution and allow for a greater target identification range, but the camera would have to be mounted on the turret.
Should we use an infrared, thermal, or regular camera?
- Should we use an infrared, thermal, or regular camera?
Infrared cameras allow a wider spectrum of light to be visible but they may have some issues with available object recognition programs.
- Infrared cameras allow a wider spectrum of light to be visible but they may have some issues with available object recognition programs.
Thermal cameras allow Quaade to see in darkness but are more expensive.
- Thermal cameras allow Quaade to see in darkness but are more expensive.
Regular cameras are the most widely available, cheapest, and have the most programs available.
- Regular cameras are the most widely available, cheapest, and have the most programs available.
What should we use for image processing?
We could upload image data to an external computer and do image processing. This would take a long time and would require somewhat complicated circuitry and code for wireless communication.
- We could upload image data to an external computer and do image processing. This would take a long time and would require somewhat complicated circuitry and code for wireless communication.
We could use the MSP for image processing. This would take a lot of time to develop image processing algorithms and circuitry to hook up the camera.
- We could use the MSP for image processing. This would take a lot of time to develop image processing algorithms and circuitry to hook up the camera.
We could use the Raspberry Pi or Raspberry Pi Zero W for image processing. This offers the best middle ground for complexity and speed.
- We could use the Raspberry Pi or Raspberry Pi Zero W for image processing. This offers the best middle ground for complexity and speed.
What should we use to “shoot” at a target?
We could shoot the target with a nerf gun. However, this would add a lot of weight
- We could shoot the target with a nerf gun. However, this would add a lot of weight
A real gun is out of the question
- A real gun is out of the question
A railgun would be really super cool but is also way out of scope
- A railgun would be really super cool but is also way out of scope
A laser is really all we need, it is easy to power and is small and lightweight.
- A laser is really all we need, it is easy to power and is small and lightweight.
As a stretch goal, how should we control Quaade?
We could use the wireless capabilities of the Raspberry Pi Zero W to give movement commands to the MSP using wifi.
- We could use the wireless capabilities of the Raspberry Pi Zero W to give movement commands to the MSP using wifi.
The same can be done but with Bluetooth, however, this requires a Bluetooth to serial converter or an app on a phone to control Quaade.
- The same can be done but with Bluetooth, however, this requires a Bluetooth to serial converter or an app on a phone to control Quaade.
Radio control can be added with more circuitry and radio control programming, but this gets a lot more complicated than wifi control with the raspberry pi.
- Radio control can be added with more circuitry and radio control programming, but this gets a lot more complicated than wifi control with the raspberry pi.
Theoretical Analysis
Power Budget
Torque Calculations for servos, stepper motors, brushed and brushless motors
Servos: We will use the SG92R servo for all joints as it is a good all-around servo (and we have a few extras that came with our kits).
Laser head:
Mass (estimate): 5g
Distance: 1cm
Calculated torque: 5g*cm
Servo: almost any servo, will use SG92R
Laser base:
Mass (estimate): 20g
Distance: 2cm
Calculated torque: 40g*cm
Servo: almost any servo, will use SG92R
Quaade leg:
Mass (max) = total / 3 (for standing on 3 legs) = (calculated) 357g
Distance: 7cm
Max torque: 2.5kg*cm
Servo: SG92R
Quaade shoulder:
Mass (estimate): 15g
Distance: 2cm
Calculated torque: 30g*cm
Servo: SG92R
Mass Budget
The purpose of the mass budget is to account for all the mass of the project so that actuators like servos, motors, engines, can be determined based on the physical requirements of the system.
Total System mass =
Legs 357g (x3) = 1,071g
Laser head & base = 25g
Quaade shoulders (15g)*3 = 45g
Quaade body = ~150-250g (depending on PCB)
Total Mass Estimation Range = 1,300-1,400g total, 1,071g of which contains the legs/base of the robot’s structural integrity and a margin of 100g error due to the inability to weigh PCB or future Quaade parts not yet designed.
Thermal Considerations (Let's get the heat out)
Thermal Considerations (Let’s make it hotter)
For each component we are using, we do not plan on reaching or exceeding their thermal limits and for this reason, we don’t plan on needing cooling solutions.
Sensors
Our project requires only one sensor to operate. Quaade can walk well enough without obstacle detection (but this may be a reach goal) and not much about the environment needs to be known to accurately point a laser at a target. A camera is the only knowledge of the outside world our project needs to function the way we want. The camera does need to have a high enough resolution to identify targets well and a high enough framerate to avoid jitter. Object recognition is a calculation that must be performed live, and it's a heavy process at that. This is why we are incorporating the powerful Raspberry Pi Zero W in this project.
Bill of Materials
This is an itemized list of what materials you need to purchase, the quantity, and the URL source. Allows us to keep track of all the different parts of the project.
Inventory Tracking Table
Github
https://github.com/willfoerster/Group_Name_Project
Hackster.io
https://www.hackster.io/projects/dfb632/edit#attachments
Final Project Video
Appendix for Citations and Links
Micro Sd Card:
Raspberry Pi HQ Camera Module:
https://www.raspberrypi.org/documentation/raspbian/applications/camera.md
Raspberry Pi Zero W:
https://www.raspberrypi.org/forums/viewtopic.php?t=248653#:~:text=Re%3A%20Max%20Power%20Consumption%20of%20Raspberry%20Pi%20Zero%20W,-Tue%20Aug%2013&text=They%20can%20supply%20up%20to%20500ma%20or%201000ma.
Laser Diode:
https://www.thorlabs.com/NewGroupPage9_PF.cfm?ObjectGroup_ID=1832
MSP432:
Servos:
https://www.orientalmotor.com/products/pdfs/2015-2016/B/Servo_Motor_Introduction.pdf
Motor Driver:
https://www.mouser.com/datasheet/2/348/rohm_BA6286N-1201604.pdf
Raspberry Pi HQ Camera Module:
https://uk.rs-online.com/web/p/raspberry-pi-cameras/9132664/
Raspberry Pi Zero W:
https://copperhilltech.com/blog/raspberry-pi-proven-to-withstand-extended-temperature-range/
Laser Diode:
https://rpmclasers.com/wp-content/uploads/products/How%20to%20Improve%20Laser%20Diode%20Lifetime.pdf
https://kb.sandisk.com/app/answers/detail/a_id/4687/~/sandisk-cards-environmental-tolerance-%28waterproof%2C-temperature%2C-magnetic-and#:~:text=Temperature%20proof%3A,(%2D25%C2%BAC%20to%2085%20%C2%BAC).
Quade Body:
http://www.stug.com.au/materials/engineering-plastics-properties/min-max-operating-temperatures.php
MSP432 Temp:
Servos:
https://community.parker.com/technologies/electromechanical-group/w/electromechanical-knowledge-base/637/operating-temperatures-for-servo-motor-brakes#:~:text=All%20motor%20brakes%20installed%20on,temperature%20of%20140%C2%B0C.
Motor Driver:
https://community.parker.com/technologies/electromechanical-group/w/electromechanical-knowledge-base/613/operating-temperature-range-for-stepper-motors#:~:text=The%20recommended%20operational%20temperature%20range,C%20to%20100%C2%B0%20C.
PCB:
http://www.nanotech-elektronik.pl/index.php/en/info/materials#:~:text=Most%20often%20printed%20circuit%20boards,supplier%20and%20type%20of%20material.
PCA9685
https://www.adafruit.com/product/815
Github:
https://github.com/willfoerster/Group_Name_Project
Hackster.io:
https://www.hackster.io/projects/dfb632/edit#attachments
Comments
Please log in or sign up to comment.