Embedded Files
Solution approach
Solution approach
The product specifications given by the sponsor were very explicit, therefore there was no need for multiple approaches to the design of the solution. The product is a 20x12x10 tank that was 3D printed and processed by a Jetson Nano and a handheld controller with a screen processed by a Raspberry Pi. The controller also has buttons and joysticks to allow the user to control the different movements on the tank. The tank uses a tread attached to DC motors to move based on the user input on the controller’s joysticks. The laser is mounted on the top of the tank and is attached to servo motors. The buttons on the controller move the laser to aim at the desired target. The GPS, camera and magnetometer are mounted directly on the laser to allow the user to see exactly where the laser is pointing, and get the most accurate result for the target’s coordinates. The tank’s components are powered by a battery board designed by Will. It is split into four boards that each have four batteries . The board is designed to cut power to the batteries when charge percentage reaches a certain level. In addition, it automatically stops the charging when the upper charge level is reached.
Overall System Design
Overall System Design
The controller and tank work as a transmitter/receiver via port forwarding. The Raspberry pi 3b+ is used as the primary display to allow viewing of the GPS coordinates, Magnetometer, Accelerometer, and camera point of view of the tank. The tank is equipped with a Jetson Nano for computing data that is being sent and received. The Jetson Nano is attached to a camera, servo motors, DC/DC motors, laser rangefinder, magnetometer, and GPS. The magnetometer, accelerometer, and GPS detect the tank’s position and its coordinates continuously. Using the OpenCV library for computer vision, machine learning, and image processing, we start up the camera and stream the video to the controller. This library allows processing of images and videos to identify objects and faces for detecting a specific target for potential future improvement of the tank design and capability. The camera is attached to both the GPS and the laser to provide an accurate reading and result. The GPS coordinates of the tank and the target are displayed on the screen as well as crosshairs to show exactly where the laser is pointing. The laser rangefinder reads the distance of the target and sends that information to the Jetson Nano to compute and send that back to Raspberry Pi to inform the user. The tank has two states, the driving state and the aiming state. At the outset, the tank is in driving mode, where only the DC motors are accessible. If movement is detected from the controller’s joysticks, the DC motors will move accordingly by sending Pulse Width Modulation (PWM) signals to the tank. When both bottom buttons are pressed, the mode switches from driving to aiming mode and you can now control the servos. The right button pad indicates movement of the tank’s servo motors. The magnetometer reads information from the tank to ascertain the tank's current direction and heading, and uses that information in an equation. The GPS is used to pinpoint a three-dimensional position to meter-level accuracy.
Components & materials
Components & materials
All the devices and the components were chosen carefully based on calculations and expectations of power supply, inputs, outputs, communication, etc. The Jetson Nano is a very powerful module that is manufactured at Nvidia. This particular module was selected based upon several factors including: its power, flexibility, and object detection capabilities. The module has a quad core processor with operating frequency of up to 1.43 GHz, Maxwell 128-Core GPU with operating frequency of up to 921 MHz, 4 GB LPDDR4 and internal memory of 16 GB eMMC. In addition to its processing and graphical capabilities, this module also provides wide peripheral interface options: 1 x USB 3.0, 3 x USB 2.0, 4-lane PCIe: one x 1/2/4 controller, single SD/MMC controller, 3 x UART, 2 x SPI, 4 x I2C, 2 x I2S, and GPIOs. The tank will be equipped with two DC motors in the back of its body to manage the torque, the stirring/direction based on the velocity of each motor, and the overall spinning velocity. The chosen brushed motors are from ROBOTZONE manufacturer (part #638328), which operates with voltage levels of 6V-12V. The maximum (no load) rotation speed and torque are 313 rpm and torque power of 30 kgf-cm, respectively. In addition to this, the DC motors’ operating current is only 0.52A (no load), which is not a high current requirement to keep the batteries’ life longer. Two Servo motors manage the movement of the laser on the tank. One servo motor rotates horizontally, and it was chosen to complete 180 degrees rotations, and the second motor moves on the vertical plane. The servo motors are manufactured by Hiwonder, and it was chosen for its voltage of 6V, rotation abilities of 180 degrees, torque of 20 kg cm, availability/stock, and price. The servo motors communicate with the Jetson Nano through the PCA 9685 module using I2C communication protocol. This controlled PWM driver has 16 channels and is compliant with 5V operating voltage and logic of 3.3V, and the frequency operation can go up to 1.6 kHz. The MPU-9250 Module was introduced to us by the sponsor, and it includes Gyroscope, Magnetometer, and Accelerometer. Gyroscope and Accelerometer are used together as a perfect combo to measure and detect orientation change and acceleration in space. The Magnetometer in the module is used for measuring strength and direction of the magnetic field around the tank to provide an indication of the surrounding area. The IC has 16-bit ADCs, and it operates at a low current of 3.2mA. At this point, we connected the unit through an I2C bus directly to the Jetson Nano using up one of two available I2C connections on the Jetson Nano. In addition to this, the IC’s voltage supply range is 2.4V-3.6V, and the communication rates of I2C and SPI stand on 400kHz and 1MHz, respectively. The GPNEO-M8P GPS Module was introduced to us by our project sponsor, and its main purpose is to provide real time position, velocity, and time information through the receiver. Moreover, using GPS and Magnetometer, we can detect not only the location of our tank but potential threats as well. This module has multiple connection options such as UART, SPI, I2C, and USB. We decided to use the USB connection as we had more open ports for USB than the other communication protocols on the Jetson Nano. One wide angle camera works with two modes of operation. It is used as a POV perspective for driving the tank, and will be hard mounted to the laser rangefinder. Originally, we planned on using a CSI camera that connects to the Jetson Nano via ribbon cable. However, we switched to using an Arducam USB camera to allow for ease of use. In addition, the USB camera allows us to place the camera much further from the Jetson Nano which is at the very center of the tank.
Battery
Battery
Tank Battery Management Flowchart
Controller Battery Management Flowchart
The battery system was divided into 2 main portions: the tank and the controller; both portions were remarkably similar. Each of them involve a battery management system (BMS) board, a battery pack, a barrel jack for charging, DC/DC converters, and protection circuits. Will designed the boards for both the tank and the controller.
The first step for both boards was to communicate with the Embedded Hardware team to determine which components will be used and calculate maximum load current and voltage requirements. Once maximum power has been determined, the team was able to pick the best batteries to use based on budget and availability. The choice of battery was the 18650 LiPo battery due to its high current capabilities. They were tied together in a 4 series 4 parallel configuration for a voltage range of 12V-16.8V at roughly 20 Amp hours. The weight of this configuration is light enough to be moved by the motors but energy dense enough to provide ample power to the system for a respectable amount of time. The controller battery system was 4 series and 2 parallel for a voltage range of 6V-8.4V at roughly 10 Amp hours. These configurations were chosen based on max/min voltage requirements and total current draw for each device.
For the tank, the circuitry reads the voltage across each individual and communicates this data back to a microcontroller that then processes the data. If any given battery has a voltage above the rest, the microcontroller will shunt all other batteries until they are all on the same level. This results in a longer battery lifetime. In addition to this, the controller will add the values together to determine the max voltage of the stack. If the circuit is in charge mode, the controller will shut off the current path to avoid overcharging the batteries. If the boards are supplying a load, the controller will cut current to the load in order to avoid over discharge. Again, the reasoning is to prolong the lives of the batteries. The charge and discharge control is done with low-side mosfets rated at 12.5A each. Originally, the top voltage of the stack was to be determined by a comparator flag that went high when the max voltage was reached and another tripped when min voltage was reached. Unfortunately, there was an issue with this design caused by the supply voltage of the opamps being equal to the voltage comparison, as a result the comparator did not work correctly. This was not an issue with the tank battery board which read the individual battery voltages into the microcontroller, but it made teh controller board pretty much unusable. Ultimately, the controller board was scraped from the project for time and resource sake. The battery boards for the tank were then placed in a parallel configuration inside of a box rack slice configuration that I 3D modeled and printed.
Finally, I designed a bus bar PCB that tied all the tank boards together in parallel. This PCB was simple to design and consists of a 2-sided PCB where Vcc is on the bottom and GND is on the top. The input and output connectors are all phoenix screw connectors. Each of the output connectors either run directly to their loads or through Buck converters before ultimately going to their respective loads, depending on voltage/current requirements.
Structure
Structure
The structural system is all-encompassing as it is required to house and protect the power and embedded systems, as well as protect them by providing the necessary resilience to inevitable external factors such as the elements, tampering, and opposing forces. Several iterations were completed to ensure that these requirements were met. Each of these iterations were machined using 3D printers; to ensure maximum functionality a 3D printer was used to create a prototype/proof of concept. The machining of each iteration was based on the structural team (Jacob Baker & Will Yerkes) designs.
The structural design of the targeting pod followed the process listed in the block diagram above and was further divided into three separate designs: the chassis/frame, the powertrain/ tread, and the shell/armor. Whereas the controller was divided into two sections: front and back.
The chassis/frame (targeting pod) is a piece that houses the components and provides a sturdy foundation for the other systems to be mounted and placed.
The chassis was modeled around the sensors and motors. The final size of the chassis and frame had to be fluid until the final equipment had been selected.
It is necessary that the housing is protected from the elements, water resistance was incorporated into the chassis design to maintain functioning power and embedded systems.
The tread/powertrain (targeting pod) were mounted to the chassis/frame and connected to motors via dual driver gears, one placed and providing power to each side. These driver gears are responsible for the movement of the vehicle and the tensile strength of the material used had to reflect the power delivered from the motors.
The connection between the motor (chassis) and the driver gear (tread) needed to be waterproofed in some way to protect the motor from any moisture accumulated on the tread/wheel system.
Several other wheels were strategically mounted to the chassis and will act as tensioners/ place holders for the tread system.
The tread is secured around the gear and the additional wheels and it provides traction for the movement of the targeting pod.
The shell/armor (targeting pod) of the vehicle has dual purpose; the shell serves as a cover/protection for the components mounted on the housing and gives the vehicle an aesthetically pleasing appearance.
The shell was designed to protect from “opposing forces” so it can serve as armor.
The maximum weight of the shell was determined based on the strength of the motors and the final material chosen was PLA.
The back controller design was where the corresponding components were placed and mounted.
The three separate designs of the targeting pod were combined, as the front and back of the controller design were. Each of these separate pieces were mated using metal screws. This final assembly resulted in both the completed targeting pod and controller that not only housed the internals of the corresponding subsystems, but also protected them from outside interference and afflictions. Many considerations needed to be made to ensure the functionality, practicality, and longevity of the targeting pod and the controller.
Software
Software
The GPS targeting pod software team will use Python as the main language to program the Jetson Nano and the Raspberry Pi. The code will read inputs from various sensors, process data, and send data between modules. Google Colaboratory Notebook will be used by the software team to develop the code for the project, because it allows multiple people to write, share, and test code in the same file. The data will be communicated between processors using wifi. The camera footage from the tank will be stored on a USB flash drive for ease of use and accessibility.
Discussion on Lessons Learned
Discussion on Lessons Learned
As mentioned in the previous section, developing a successful product wherein, hardware and software operates effectively requires a thorough process and attention to every detail where all the factors need to be considered. Although the developing steps were built carefully, there is always a place for improvement throughout the process.
The first takeaway is related to the initial developmental research and its components. Since electronic components and devices can be very sensitive to ESD and excessive power in general, it is always important to have an extra pair of components when developing a new prototype. It is important to keep the workflow in case a device gets fried for any reason. For instance, during the development process, the camera sensor on the CSI camera stopped working and we did not have an extra camera of the same model. Luckily, we could switch from a CSI to USB camera thanks to the availability; however, the software section had to change accordingly for the communication. In some cases replacing a component can be very tricky due to availability and lead time from the manufacturers, differences in its operation, change in design, etc. In addition to this, the chosen camera did not meet our quality expectations, especially for a device that is heavily dependent on targeting via the camera. Thus, the initial research plays a crucial role in finding the best components for a development.
The second takeaway is taken from designing electrical circuits and PCBs. Unlike software bugs and errors, replacing or changing hardware is complicated and often requires a new design. In our development, multiple PCBs were created and when one of the tested boards was not operating the way it was supposed to, the circuit was tested then on a breadboard with all the components to confirm full functionality. When the new PCB was designed in KiCad, a few additional “non-populated” resistors were added in parallel traces to be able to pull the pins high/low in case of an error. This solution maximizes the chances of having a fully functional board with easy fixes if and as needed.
Lastly, learning and knowing all the up to date technologies that are available can significantly improve and speed up the development process by saving time and sometimes cost factors as well. For instance, one of the main challenges in the development was the communication between the Jetson Nano on the tank and the Raspberry Pi on the remote controller. Initially, the plan was to use Wi-Fi for fast communication between the devices; however, accessing the school’s port was not an option. Then, we were advised to use a small router to create a Wireless Local Network Communication (WLAN) and use Transmission Control Protocol (TCP) to establish safe data exchange and communication between the devices. TCP communication worked well; however, it was slow and did not fulfill our needs. Then, the next alternative was using User Datagram Protocol (UDP) which is much faster than TCP due to the fact that this protocol does not need acknowledgement of the sent packets. Although engineering is about testing and evaluating different solutions, learning about the potential technologies could save us a lot of development time.
User Interface & Data Communication
User Interface & Data Communication
The user will interact with the GPS targeting pod using a handheld controller powered by a Raspberry Pi 3. The controller will be equipped with buttons, joysticks and a display with a continuous live point of view feed from the tank. This will allow the user to have a better understanding of the tank’s position and determine the best future movements to complete the desired task. In addition, the user will be able to record the feed directly to a removable flash drive, which enables one to easily remove and replace the storage device. With this feature, the tank can be redeployed and past footage can be reviewed simultaneously. The controller will communicate with the tank using a wifi connection. The Raspberry pi has built-in wifi connectivity, and a wifi card will be placed in the Jetson Nano used in the tank to allow for wifi connection. The controller will send information to the tank based on the user’s input, and receive the camera feed from the tank. The buttons and joysticks will connect to the controller using the general purpose input/output(GPIO) pins.
Testing & Calibration Results
Testing & Calibration Results
Testing is an integral part of product creation, as it is important to make sure the individual subsystems are functional before putting everything together.
Structure:
The prototype of the tank chassis was designed and printed with less infill to reduce waste and make sure all the measurements were accurate and the design was effective. After confirming the size, shape, and integrity of the body, the chassis was assembled to verify that everything fit together. Then, the mounts were measured and placed inside the tank to make sure all the modules would be able to mount properly without shorting any components. The modules were then removed to perform a stress test on the chassis to verify its stability. A few different designs of the controller were created and printed to test with the display screen and the controller components. The design that provided the best user experience was chosen as the final design.
Battery:
The testing of the battery subsystem is extremely important, because the entire system is dependent on the operation of this power system. Before designing the board, it was essential to verify the availability of the desired components. The circuit designs for the tank and controller were constructed and verified with advisors many times to ensure the best design was being used. Next, the PCB layout was created and confirmed with advisors before ordering. Finally, the boards were ordered, populated, and fabricated using solder paste, stencils and reflow oven. The performance was verified using demo code, and an oscilloscope.
Embedded Hardware:
The availability and price point of the desired embedded components were verified before the programming could commence. The power requirements for the components were verified and checked with the battery team to make sure they would have the proper voltages for power buses. The communication protocols of each component were verified and cross checked with the pin maps of the processors to make sure they were usable.
Embedded Software:
Before creating a program that included all of the required functionality specified in Section 3.1, each component had to be programmed and tested to make sure that the proper values were being retrieved. The GPS uses a USB to communicate with the Jetson Nano, so once the USB port is specified, the GPS coordinates can be retrieved and cross checked with Google. The laser is also connected using a USB and the accuracy of the distance returned was checked with a caliper. The USB camera stream was tested many times over, because of the delay and choppy images that were being received. The stream was upgraded by splitting the frames into packages before they were sent. The magnetometer uses I2C to communicate with the Jetson Nano, the testing of this function was completed using a library for the component. The values retrieved were verified using a compass and a bubble level. The individual DC motors and motor drivers were each tested with a power supply to ensure they were operational. The operation of the joysticks and buttons were verified using an analog to digital converter and the GPIO ports respectively.
Circuit Diagrams
Circuit Diagrams
Pictured in the first photo is the voltage reading and shunting circuits for the battery stack. The battery voltages are first passed through a buffer that is referenced to the top of the battery stack to ensure there is no current drawn from the center of the stack. Then those values are passed through differential amplifiers with a gain of 1 to calculate the voltage of each individual battery. And finally, the microcontroller can output to optocouplers to shunt the batteries, resulting in the ability to drop battery voltages as necessary.
The second photo displays all the elements related to power distribution of the board. There is a barrel jack for easy charging, low side switches for controlling max charge and discharge values, a buck converter to power the microcontroller, and comparator flags to determine when max charge and discharge values are met.
The third photo is the image for all the control of the battery boards. There are header pins for input and output communication, an ATMEGA328P microcontroller, and a button for reset when programming.
The schematic in the last photo is designed to measure the voltages of all 16 batteries using a 16 channel input multiplexer (CD74HCT4067) to convert the analog signals to digital with an Arduino Nano microcontroller, and then demultiplex the battery voltages to track the charge levels.
Jetson Nano Pin Connections
Jetson Nano Pin Connections
Page updated
Google Sites
Report abuse