Mobile pet entertainer a constructive analysis of building a robotics application for interacting with pets

In this project, we design and build a robot to enable remote interaction with pets. This project follows a chain of recent remote-controlled pet products, but aims to provide a wider range of interaction. The robot features a four-wheel tank-drive chassis, carrying an arm capable of dangling small objects or toys, and directing a laser pointer. The robot is controlled via a networking mobile application. The user interface displays feed from onboard cameras, and provides the ability to move the robot. The resultant prototype functions as designed, though it is notably not pet-safe. The design is unlikely to be viable as a commercial product due to high component costs, but instead speaks to the potential of technology in pet interactions.

MOBILE PET ENTERTAINER A constructive analysis of building a robotics application for interacting with pets by Daniel Avery A Senior Honors Thesis Submitted to the Faculty of The University of Utah In Partial Fulfillment of the Requirements for the Honors Degree in Bachelor of Science In Computer Engineering Approved: ______________________________ Angela Rasmussen, PhD Thesis Faculty Supervisor _____________________________ Florian Solzbacher, PhD Chair, Department of Electrical and Computer Engineering _______________________________ Neil Cotter, PhD Honors Faculty Advisor _____________________________ Sylvia D. Torti, PhD Dean, Honors College April 2018 Copyright © 2018 All Rights Reserved ABSTRACT In this project, we design and build a robot to enable remote interaction with pets. This project follows a chain of recent remote-controlled pet products, but aims to provide a wider range of interaction. The robot features a four-wheel tank-drive chassis, carrying an arm capable of dangling small objects or toys, and directing a laser pointer. The robot is controlled via a networking mobile application. The user interface displays feed from onboard cameras, and provides the ability to move the robot. The resultant prototype functions as designed, though it is notably not pet-safe. The design is unlikely to be viable as a commercial product due to high component costs, but instead speaks to the potential of technology in pet interactions. This project constituted a joint effort between the author and fellow undergraduate Jeremiah Pope ii TABLE OF CONTENTS ABSTRACT ii INTRODUCTION 1 PURPOSE 3 SOLUTION 4 CONSTRAINTS 6 METHODOLOGY 7 Part 1: Selecting Hardware to Move the Robot 7 Part 2: Controlling Motor Speed 9 Part 3: Receiving Commands 11 Part 4: Improving Safety of Communications 13 Part 5: Giving the Robot a Body 14 Part 6: Wiring the Robot 17 Part 7: Crafting Mobile Applications 18 RESULTS 19 CONCLUSION 22 APPENDIX 23 REFERENCES 24 iii 1 INTRODUCTION With the dawn of ubiquitous tech, recent products have emerged to answer the desire for pet interactions in new and interesting ways. One such solution, implemented by the crowdfunded projects PlayDate [1] and Pebby [2], is a remote-controlled “smart ball” with a stabilized embedded camera. These devices, mainly targeting owners with dogs, allow owners who are away from home to connect over WiFi and play with their pet via a mobile application. The application displays camera feed and enables owners to move the ball around, engaging in lead/follow/chase interactions with their pet. Additionally, both devices offer two-way communications via an onboard speaker and microphone. Pebby also includes a laser for point-and-chase interactions, and an associated activity tracker that clips onto a pet’s collar to monitor movement and collect metrics for the app to display. A similar solution, implemented by the GoBone [3] product and exclusively for dogs, comes in the form of a “smart bone.” Like the smart balls, GoBone offers a mobile application to remotely control and move an object resembling a dog bone around. Unlike the smart balls, GoBone offers enhanced capabilities such as recording video. It can also operate in a completely autonomous mode, moving about randomly or playing back previous movements. This mode can be scheduled to activate periodically, generating pet interest and facilitating activity even when the owner is away and preoccupied. A third solution comes in the form of Pawly [4], another crowdfunded project. This device is more of a remote-controlled car, with four wheels. It comes with a camera for streaming video to a mobile application, as well as a speaker and microphone for twoway communications. Unfortunately, the device seems to have never released even as a 2 beta. Certain attachments that appeared in concept video, like a laser pointer and “treat blaster,” also do not appear to have made it to a physical build. 3 PURPOSE In the previously mentioned tech solutions to remote pet interaction, there are a number of good ideas being employed. However, all of the existing solutions fall short in a critical way: they provide very limited modes of interaction between owners and pets. Most of these are lead/follow/chase interactions that not only rely on the pet being of a particular demeanor to engage, but can also easily be disrupted if a pet picks up the toy in its mouth. The project that showed the most promise to overcome these issues and provide a broader spectrum of interaction, namely Pawly, failed to get off the ground. This leaves much to be desired in the way of having meaningful interactions with pets remotely. In this project we aim to address that concern directly. In particular, we explore a design that would facilitate several common owner-pet interactions at once, even while the owner is away from home. We mainly investigate the technological challenges of developing such a prototype solution, keeping in mind safety and reliability concerns throughout. Finally, we briefly look at the commercial feasibility and social implications of our creation. 4 SOLUTION To address the need for a broader range of accessible owner-pet interactions while the owner is away from home, we design and build a remotely controlled robot that is highly mobile and equipped for several common interactions. Like the aforementioned devices, this robot is controlled via a mobile application user interface. The robot itself consists primarily of a robotic arm mounted on a four-wheel chassis. The wheels operate in “tank-drive” mode, meaning the chassis can turn only by moving the wheels on either side in opposite directions; it cannot change its heading while moving forward or backward. The arm sits atop a turntable, such that the heading of the arm can be adjusted independently of the chassis. The arm’s pitch can also be adjusted, as well as its reach: the tip of the arm can move inward and outward. To allow easy control of the robot from elsewhere, we install two onboard cameras, one to the chassis and one to the arm. Upon connection, the feed from these cameras is streamed over WiFi and displayed on the mobile app. The mobile app in turn receives commands from the user that are propagated over the network and eventually drive onboard motors and actuators to move the robot. Fig. 1: Early concept sketch of the robot design 5 To facilitate point-and-chase interactions, we affix a laser pointer to the arm. The laser pointer can likewise be turned on/off via the mobile app. While the current design does not include an anticipated “hand” attachment for picking up and releasing objects, this would be an easily supported accessory. For the time being, we use the tip of the arm for dangling toys, allowing for batting or tug-of-war interactions. We also currently forego two-way communications with a speaker and microphone, which may be desirable in many cases, but unnecessary if the user is under pressure and wishes to interact with their pet discreetly. 6 CONSTRAINTS The proposed solution has little in the way of environmental or sustainability concerns, other than standard robotics parts manufacturing processes, which we will not explore in this project. The proposed solution does pose health and safety concerns for users and pets, which are mitigated in several ways. Mainly, we aim to prevent accidental pet injury or property damages a user could affect due to inadequate systems design. First, we take a careful approach throughout the line of communications, opting for simple command structures and fast-shutdown mechanisms. Second, we attempt to minimize latency in the line of communications, ensuring that user commands are enacted and confirmed to the user promptly, before the user feels compelled to repeat them. Third, we design the user interface to be simple and easy to understand, while also giving the user live video feedback on their actions. We take these steps seriously to ensure a safe and reliable experience for owners and pets alike. Lastly, we consider the economic impact of the proposed solution. At each purchase we aim to strike a balance between low costs and reliable components. While not strictly bounding expenses, we try to keep the total cost at or close to $1000. In the end we tally costs with consideration for commercial viability of the design. 7 METHODOLOGY Fig. 2: Block diagram of laptop-controlled robot system communications Part 1: Selecting Hardware to Move the Robot The first step in building the robot was picking appropriate motors and actuators, as well as motor controllers, and a power source, to use on the robot. Making these 8 decisions first was important because the nature of our embedded communications would depend on what media were necessary to interface with these moving parts. We chose to use three VEX Mini CIM motors ($25/ea.) to drive the wheels on either side of the robot, and to turn the central turntable that we would mount the arm on. These motors have the benefit of being both inexpensive, well documented, and tested, as they are used commonly in FIRST Robotics competitions [5]. For the arm itself, we chose one slow 6” linear actuator from Windy Nation ($60), and one fast 24” linear actuator from Firgelli Automations ($150). The actuators were harder to source, as we had to carefully weigh the generally higher costs against desirable speed and stroke length. We would eventually need motor controllers for each of these devices, but for the first stage of our implementation, we ordered just one VEX Victor SP motor controller ($60). This part was designed to work with the Mini CIM motors, and thanks to hardware convention would likely be compatible with the actuators, but we would need to verify and test. Finally, we also selected a 12V 18Ah sealed lead acid battery ($40) to power the motors and actuators. We compared to Nickel Cadmium, a common and more expensive alternative, but found lead acid to be better suited to infrequent use, having imperceptible daily losses on the shelf vs. 1% loss/day with Nickel Cadmium [6,7]. This, and cost savings, were desirable qualities for a prototype design that would not see consistent daily use. The battery voltage (12V) was chosen to align with the voltages expected by the motors and actuators. The current ratings were likewise acceptable given an anticipated current load of 15A (3A free current/motor, five motors in parallel). With 9 18Ah, we could expect somewhere between a half hour and an hour of use per charge, under normal (free current, little stall) operating conditions. We also considered max current output and motor stall currents, which is discussed in more depth in Part 6. With these pieces purchased, we ran preliminary tests to ensure that the battery could power the motors as expected. We direct-connected each motor/actuator to the battery leads, causing them to move at full speed in one direction. This assured that none of the motors were defective. Next, we would need to test each motor with the motor controller, by wiring each motor in turn to the motor controller and providing the controller with a PWM signal it could use to drive the motors at a given speed and direction. Part 2: Controlling Motor Speed With the machinery of motion selected, we needed a microcontroller to generate a PWM (Pulse Width Modulation) signal to drive the motor controller. PWM is a commonly used digital control signal that uses “duty cycles” to convey information to another device (in this case, a motor controller). Duty cycles specify what percent of the time the control signal is high vs. low. To work with any given hardware, the signal must alternate within a hardware-specified time period. For our motor controllers, this period was 3 ms. A duty cycle of 66% would mean that every 3 ms, the signal stays high for 2 ms and goes low for 1 ms, before repeating (“cycling”) the same thing again. For their part, the motor controllers would interpret this incoming control signal to drive the motors. In this case, a 50% (“neutral”) duty cycle would be interpreted as a STOP signal, 10 while 66% and 34% duty were full speed in opposite directions. By feeding the motor controller a PWM between 34% and 66% duty, we could finely specify the speed and direction of the motor that motor controller was wired to. Fig. 3: Saleae capture of 3 ms PWM at 50% duty cycle (“neutral” – motor STOP) Fig. 4: Saleae capture of 3 ms PWM at 66% duty cycle (motor full speed forward) Fig. 5: Saleae capture of 3 ms PWM at 34% duty cycle (motor full speed reverse) 11 For the microcontroller that would generate these PWM signals, we went with the STM32F072 Discovery board ($15, times two), which is both inexpensive, and had the advantage that we were familiar with it from embedded systems classes. At this point it is worth noting that we decided to duplicate the microcontroller communications, such that the robotic arm and wheeled chassis would actually be controlled entirely independently by two separate microcontrollers. This was done primarily to avoid exceeding the number of PWM-enabled timer peripherals on the Discovery board, but also to limit the wires crossing between the wheeled chassis and the rotating arm. Aside from being inexpensive, the Discovery board includes a variety of built-in software-configurable peripherals. In particular, we configured several onboard timers to output 3 ms PWM to hardware-mapped pins for those timers. At this point, we were able to connect a Saleae Logic Analyzer to the pins to capture the PWM signal and confirm that it was being generated correctly. We then wrote a short program for the Discovery board to test the PWM on the motors, by periodically adjusting the duty cycle within the 34% to 66% range. With the motor controller receiving signal from the Discovery board and powering the motors, this program had the expected effect of driving the motors/actuators throughout their speed spectrum, from full reverse to full forward. Now we had confirmed that both the motors and the motor controller functioned correctly. Part 3: Receiving Commands We still needed a mechanism for receiving commands over a network connection, which unfortunately the Discovery board is ill-equipped to do. Instead, we introduced 12 Raspberry Pi 3’s ($35, times two; duplicated like the microcontroller) into the line of communications. The Raspberry Pi would be responsible for receiving user commands from the mobile app over a TCP connection, then forwarding those commands downstream to the Discovery board. The specific means by which the Pi communicates to the Discovery board is a Universal Synchronous Asynchronous Receiver Transmitter (USART) bus, a peripheral that both boards include. On the Discovery board we had to configure USART manually, and parse incoming command bytes likewise. On the Pi there were software libraries available to ease transmission. At this point it is useful to consider the full line of communication we devised. A command originates from a user interacting with the user interface (UI) in some way (e.g. pressing a button or swiping a screen). The UI code interprets this user input to mean something, like moving a motor at a speed. It then stores that translation in a JSON structured format. The JSON packet is sent across a network connection (using TCP sockets, encrypted with TLS). The packet is received by a Raspberry Pi onboard the robot, where it is converted to a more compact byte representation. That byte representation is sent over USART to the Discovery board, which finally acts out the command by setting the duty cycle of the PWM going to the appropriate motor controller. A keen observer might ask why the system uses the additional Discovery board microcontroller, when PWM generation can be handled by the Raspberry Pi itself. While it is true that the Pi can output PWM, it does not have as much dedicated hardware available for PWM generation. The Discovery board is responsible for managing up to three PWM signals at a time, which it does by configuring timer peripherals and then 13 letting them run in the background. The Pi only has one PWM-enabled timer. Thus, if the Pi had to assume this job, two of the three PWM signals would have to be continuously generated by software, not only complicating the code but competing for CPU time with other concurrent code (notably the high-bandwidth camera streaming code). This may still have been feasible, and would have had the advantage of avoiding the extra complexity of USART communications, but here we opted for more modularity to simplify concerns at each device. Part 4: Improving Safety of Communications With regards to safety and reliability, there are a couple more improvements we made in the line of communications. The first was an implementation detail to spare the motors from overly optimistic user speed adjustments. That is, if the user immediately switches a motor from running full speed in one direction to full speed in the opposite direction, this puts a large undue torque on the motor, which would be magnified by the inertia from the weight of the robot behind it. This is bad for the lifespan of the motor. To avoid this, the Discovery board uses an additional timer for ramping toward target duty cycles. When a command is received over USART, the target duty cycle for the appropriate motor controller is set, and then the actual duty cycle is periodically incremented toward that target. The exact period for this increment is the rate at which the newly introduced timer generates software interrupts. This is currently configured to happen every 40 ms, allowing a motor to transition across the 33 speeds between full forward and full reverse in about 1.3 seconds. 14 The other improvement to communications had to do with monitoring network connection. To minimize network bandwidth required to send commands, we had already opted for a strategy of sending a single JSON packet across the network whenever a motor’s speed was changed. The TCP connection would ensure that this packet was resent until it was received, but only processed once. The problem with this approach is that we have to anticipate worst case scenarios. In particular, the network connection could be lost at inopportune times: for example, before a motor is sent a STOP command. By nature of TCP, this connection loss would go undetected, leaving that motor to keep moving indefinitely at whatever speed it was last set to, and the robot could cause all sorts of havoc while the user has no control. To avoid this scenario, we added a “keep-alive” packet to the network communications. This packet is sent by the mobile application regularly, about once every quarter second. The Pi listens for this keep-alive, an indicator that the connection persists even when no command packets are being sent. If it receives no keep-alive for over two seconds, the Pi assumes that the connection was lost, and sends STOP commands across USART to the Discovery board, halting the motion of all motors onboard the robot. Part 5: Giving the Robot a Body With the full line of communications in place, it was time for the robot to take on a physical form. This required many mechanical design decisions and purchases, as well 15 as further machining. Due to the volume of purchases, costs will be excluded in this overview, but are retained in the Appendix. To start, the chassis material was chosen to be 80/20 aluminum. We ordered three 5’ segments, which were cut to form the sides of a rectangular 26” x 14” frame. An additional two 14” segments were laid as cross beams to support the eventual turntable. Finally, one more 14” segment stood upright as a center pole on the central cross beam, which would serve to give the arm height. The turntable itself would be an aluminum ring with two tracks, assembled with ball bearings in between, such that each track was free to rotate relative to the other. The outer track was bolted down in three places to the cross beams, with the center pole passing through the center of the turntable. To the inner track, we epoxied a #32 chain, which would catch a sprocket on the axis of one of our motors, controlling rotation of the inner track. The smaller actuator was bolted at the base to this inner track, acting as an adjustable, rotating lever arm for the entire robotic arm. We had intended to allow unfettered rotation of the robotic arm. We conceived of a scheme to accomplish this without tugging wires, by machining a copper track and attaching it to the underside of the turntable’s inner track. We would then station a conductive brush under the copper track to maintain constant contact with it. Then we would transfer power between these conductive surfaces, safely bridging the different inertial reference frames. Not only did this scheme prove intractable, but too late in the assembly we discovered that a solution already exists to this problem: slip rings. Slip rings solve the problem essentially the same way we had planned, with a static brush against a rotating 16 ring [8], but they must be professionally manufactured. An improved rendition of the design would utilize slip rings to allow wires to safely cross between the wheeled chassis and the rotating arm, without risk of tugging, and would enable the arm to rotate indefinitely in either direction. As is, we simply fell back to directly connecting the wires, and are careful during operation to not rotate the arm far enough that the wires are yanked. Given the 3’ length of the longer linear actuator, the actuator itself was used as the upper base of the robotic arm. It is mechanically attached to the rest of the robot at two points: the top side of the smaller linear actuator, and the top of the center pole. In order to allow this actuator to rotate with the bottom turntable, an additional small turntable was added on top of the center pole. The bottom and top turntables are directly connected via strips of metal to improve stability of the arm during rotation. On the wheeled chassis side, motor gearboxes are clamped to both of the longer sides of the frame, housing one motor on each side. Each motor turns both wheels on its side: one via gears connecting the motor shaft to a wheel axle, and one via a belt and pulley connection between the wheel axles on that side. The bottom of the robot is formed by two pieces: half by a sheet of plexiglass and half by a sheet of metal. The metal half holds the large 12V battery, while the plexiglass half holds the microelectronics that control the wheeled chassis (the microelectronics for the arm are attached directly to the long linear actuator). Approximately 100 nuts and bolts hold the whole assembly together. 17 Part 6: Wiring the Robot With the structural frame ready to go, the robot still had to be electrically connected. The motors were already positioned on the robot, and the battery and microelectronics had a place to sit. This left placing the motor controllers. Two motor controllers were bolted to the center pole of the robot, closest to the pitch and reach linear actuators that they would control. The remaining three motor controllers were bolted to the forward cross beam, near the motors controlling the wheels, and the motor controlling rotation of the turntable. To protect against current surges damaging equipment, precautions had to be taken to limit current flow around the 12V battery, motors, and motor controllers. Electrically in front of each motor controller was placed a 40A auto-reset circuit breaker, as recommended by the Victor SP specs. Lastly, since the battery has a max current rating of 120A, we placed a 100A circuit breaker electrically behind the battery leads. In the event the current ever got that high (we normally expect it to be around 15A), the breaker would trip and the entire bot would go dormant, waiting to be manually reset by pressing a button on the breaker. The ability to manually open and close this breaker means it can double as an on/off switch for the robot, and we use it for that purpose to avoid draining the battery. To make things easy, the microelectronics used different power supplies. Each Raspberry Pi was connected to a 5V 2400mAh power bank, and the Pi’s in turn powered the Discovery board microcontrollers. This provided the added convenience that the 18 microcontroller circuitry (and particularly the Pi servers) would not have to be restarted if the larger battery was disconnected (100A breaker turned off). Part 7: Crafting Mobile Applications Finally, the entire electrical/mechanical design of the robot was complete. What remained to be done, was taking our initial version of a user interface (which ran on a laptop), and porting it to mobile apps that run on Android or iOS. We decided to accommodate both platforms natively. For Android, we rewrote the laptop app in Java with Android Studio. The user interface provides a home screen for specifying the IP addresses of the two Raspberry Pi servers onboard the robot. These servers are assigned a static IP by a local router, which must be known. Once the IP’s are provided and a secure network connection is established, the app begins displaying video streamed from the Raspberry Pi cameras on the robot. The video stream is managed by external library LibVLC, which we had originally chosen on the laptop to be compatible with several mobile platforms. We overlaid interactive widgets atop this video display, allowing for intuitive control of the robot. The app has one screen per camera, and the user can flip between screens. Depending on whether the camera belongs to the robotic arm or the wheeled chassis, the widgets control either arm motion (e.g. heading, pitch, reach, laser pointer) or chassis motion (the wheels). When the application is closed, the network connection is likewise gracefully closed, and the robot goes dormant. On the iOS side of things, much of the user experience is similar. The primary difference is that, taking advantage of Xcode’s Interface Builder, we replaced the 19 overlaying widgets with gesture recognizers. This allows for an arguably more “natural” interface, with reduced clutter, and enabling movements like pinches and swipes to control the movement of the robot. 20 RESULTS Fig. 6: Photo of final build of the robot The complete system allows a user to control a highly mobile robot via a simple mobile application interface, as desired. The user first specifies the IP addresses of the two onboard Raspberry Pi servers, allowing the app to establish a WiFi connection to the robot. From there the user is free to use the interface to maneuver the robot in various ways, while receiving live video feed of the robot’s perspective. There are several limitations on the current version of the robot system, which would need to be resolved in a commercial product. The first and most glaring is that the robot is, ironically, still unsafe for testing with live animals. The exposed live wiring and electronics require all in proximity to be mindful. This makes the uncovered robot hazardous to pets, and also vulnerable itself to larger or more aggressive pets. The simple solution is to craft or 3D-print shielding to cover the wiring and electronics, but this level of finish is beyond the scope of our prototypal project. 21 Other concerns include incomplete end-to-end security around communications. In particular, the video stream from the Raspberry Pi cameras remains unencrypted, owing to the current use of software libraries that allow this feature being insecure implementations. This is especially concerning for a robot that would primarily reside in the home. However, for the sake of the prototype, these software libraries were useful in offering a preview of low latency video streaming. The security around the command streaming, though much better, is also incomplete. There is still no server-side authentication of the client mobile apps. Additional work would add a username and password requirement to establish a connection. In the mechanical design realm, one helpful improvement would be the addition of a slip ring for wires crossing between the wheeled chassis and robotic arm reference frames. This would allow unfettered rotation of the arm without fear of yanking wires, a constraint that is easy to forget about when remotely controlling the current version of the bot. Electrically, it would be better for all onboard circuitry to use the same power source, rather than the current method of powering microelectronics separately with power banks. This would not be a large undertaking. Mainly it would require a voltage stepdown from the 12V battery to a 3V supply. But possibility of full battery discharge is a larger problem for a robot with only 30-60 minutes of battery life. A commercial system would probably incorporate battery charge monitoring, as well as a dedicated recharge station. 22 Earlier we mentioned the possibility of a robotic hand accessory. This attachment would very much increase the dexterity of the robot, allowing for picking up and tossing objects. Taken to extremes, such attachments could even allow the robot to transcend the realm of pet interactions and facilitate a kind of home check-in and monitoring. It is worth noting that the prototype bot created in this project performed networking using a dedicated router to assign locally static IP’s to the onboard Raspberry Pi servers. A commercial solution would require making these servers globally discoverable, and perhaps introducing a web service layer to route mobile app users to the servers on the robot they purchased, based on login credentials. Finally, while the decision to duplicate microcontrollers onboard the robot simplified implementation and allowed us to consider the robotic arm and wheeled chassis separately, it is worth investigating whether a single Raspberry Pi could take the place of the two Discovery boards and two Pi’s. If feasible, this would not only reduce the number of devices involved in signal wiring, but drive down some of the cost. 23 CONCLUSION While the robot we constructed works as a functioning prototype, it would still have a long road ahead to becoming a commercial product. Even if the recommended modifications were made and the system was professionally recrafted, there is still a larger hurtle lying in the way of commercialization: cost. We hinted at component costs in the early stages of design, which were already high. Mechanical design certainly poses additional costs on the construction. Our total cost to build exceeded our $1000 soft limit by $157 (see Appendix). Even $1000 was a massive allowance by commercial standards. PlayDate, Pebby, and GoBone all sell for around $200 [1,2,3]. Pawly, which never sold, was slated at around $400 [4]. We anticipate that there are savings to be found with this design: components could be scaled down or even further optimized away for cheaper solutions, and bulk orders could cut costs. However, as is, this design is not in the ballpark for commercialization. Instead, we see the Mobile Pet Entertainer as an example of what may lie ahead. As tech continues to grow, sometimes products that were previously economically intractable become cheaper, and eventually gain an audience. For now, the realm of remote pet interaction is dominated by novelties that capture glimpses of emerging capabilities. In the future, it may be that people never feel very far away from home, or the furry friends waiting for them there. 24 APPENDIX Line Item Expenditures Component Vendor 12V 18Ah ExpertPower Battery 6” Slow Linear Windy Nation Actuator 24” Fast Linear Firgelli Actuator Automations Mini CIM Motor VEX 2”x1”x5’ 80/20 VEX Chassis Segment Aluminum VEX Bracket Motor Gear Box VEX Motor Gear VEX Bearing VEX 3’ Hex Axel VEX Wheel Mount VEX Hex Bore Wheel VEX Lock Collar VEX Fasteners (Nuts Lowe’s Home & Bolts) Improvement Victor SP Motor VEX Controller Timing Belt VEX STM32F072 STMicroelectronics Discovery board Raspberry Pi 3 Raspberry Pi Raspberry Pi 3 Raspberry Pi 5MP Camera Wiring/Crimps Ra-Elco Quantity Unit Cost 1 $35 Component Cost $35 1 $60 $60 1 $150 $150 3 3 $25 $25 $75 $75 14 $2.50 $35 2 4 8 1 2 4 12 1 $10 $16 $5 $12 $15 $15 $3 1 $20 $64 $40 $12 $30 $60 $36 $20 5 $60 $300 2 $15 $30 2 2 $35 $15 $70 $30 1 1 $15 Grand Total: $1,157 25 REFERENCES [1] "PlayDate: Play with your pet dog or cat. Anytime. Anywhere.," Startplaydate.com, 2017. [Online]. Available: http://www.startplaydate.com/. [Accessed: Sep-2017]. [2] "Pebby – Pebby," Pebby, 2017. [Online]. Available: http://www.getpebby.com/pebby/. [Accessed: Sep-2017]. [3] "GoBone - All-day play for you and your dog," Gobone, 2017. [Online]. Available: https://mygobone.com/. [Accessed: Sep-2017]. [4] "Pawly, a new way to play," Pawly.co, 2017. [Online]. Available: http://pawly.co/. [Accessed: Sep-2017]. [5] “Mini CIM Motor – VEX Robotics,” VEX Robotics, 2017. [Online]. Available: https://www.vexrobotics.com/217-3371.html. [Accessed: Sep-2017] [6] M. Goodman, “Lead-Acid or NiCd Batteries?,” Harris cyclery. [Online]. Available: https://www.sheldonbrown.com/marty_sla-nicad.html. [Accessed: Sep-2017] [7] “Isco Nickel-Cadmium and Lead-Acid Battery Comparisons,” Isco Tech Bulletin, vol. 1, no. 5, pp. 1–4, Apr-1994. [Online]. Available: http://www.clippercontrols.com/content/Nicad_vs_LeadAcidBatteries_TechBulletin.pdf. [Accessed: Sep-2017] [8] “Slip Ring Definition | Rotary Systems,” Rotary Systems, 2018. [Online]. Available: https://rotarysystems.com/support/faqs/slip-ring-definition/. [Accessed: Apr-2018].