FredBot; the Free Education Robot

Tabor Henderson Lab Assistant Department of Physics Metropolitan State University of Denver July 23, 2013

Abstract This paper describes an open-source hardware platform (FredBot) intended as a candidate replacement for the blackbox-style lab platforms provided by Pasco and other educational lab equipment manufacturers. We discuss the educational opportunities provided by open-source hardware, as well as the expected diculties. We begin with our motivations, then replicate a Pasco data set with FredBot, and compare the two sets. From this comparison, we develop our ideas for next steps. We conclude that open source hardware provides remarkably complete data and a holistic learning experience, but requires thorough development before deployment.

Motivation

The undergraduate physics lab currently uses Pasco products for almost all of our equipment needs, including physical items like kinetics tracks and carts, and electronic components, like the 750-series interface box and sensors. While generally well-made, the Pasco equipment is very expensive. The 750-series

boxes cost over $700, and have already been replaced by the 950-series, which costs $900. These devices mediate between the lab computers and sensors, and this is where I rst realized how easily they could be replaced. This is also the biggest aw in Pascos products; they all rely on the interface box, forcing experiments to rely on real-time communication between the desktop and sensors. Our biggest problem with the Pasco equipment has been the interface boxes, almost always with their USB rmware. FredBot avoids this issue entirely by design, but it comes with a loss in educational experience. FredBot trades the ability to view real time data for a transparent, open platform. Pascos approach is a blackbox style design, in which the students dont need information on the nature of their data-collection apparatus. With this design, students dont need to understand that their motion sensor is actually a position sensor, only that it provides data up to a certain accuracy.
1

With FredBot, we pursue three design elements: reliability, clarity, and cost. FredBot is essentially bulletproof by way of modularity. If any component fails, it is replaceable for less than $30. FredBot also functions completely transparently; it relies on less than 40 lines of code, and all functions are explicit. There is no motion sensor with FredBot; only a position sensor, a datalog, and the students ability to manipulate that data. Finally, the current version of FredBot costs less than $100 plus assembly time, and could provide serviceable data in most of our kinetics labs.

Description of Materials

The Arduino open source prototyping platform is the core of FredBot. It includes a development environment with many libraries. In fact, we did not
1 As a student, the author personally beneted from this. Watching the real-time graph of kinetic vs. potential energy was fascinating, and a powerful learning experience. This advantages are lost with FredBot, but may be recoverable with additional development.

write more than 10 lines of code for the main program; it simply consists of two pieces of integrated library code. A major feature of the Arduino platform is its shield system. This allows major components to be dropped in and expanded further by the user. Available shields include our memory module listed above, various types of wireless communication, touchscreens, high voltage controllers, sensor relays, and more. Additionally, shields always leave at least some of the mainboards pins open for other sensors. We utilize both features in FredBot. FredBot itself is simply the components above assembled in the enclosure. It is suciently compact to be mounted securely to the Pasco kinetics carts with velcro straps. The Ping))) sensor needs a fairly large target. We mounted FredBot to the cart, allowing the target (10.012.5cm cardboard sheet) to remain stationary. This provided initial data, but it was not easily comparable to Pasco data. So, we collected data using both systems in a consistent way, described below.

Description Arduino Uno Rev 3 open source prototyping board Seeed Studio SD/mSD shield Parallax Inc. Ping))) Ultrasonic distance sensor Radioshack Enclosure Project Skeleton Kit battery pack & miscellaneous connectors total

Cost $25 $10 $30 $25 $5 $95

Data Collection Procedure

To compare the two data collection systems, we collected position data from the end of a kinetics cart, with the ultrasonic senors pointing at the cart in both 3

cases. We collected data on a kinetics cart standing still, as it fell down an inclined track, and after an impulse away from the sensor. Due to dierences between the systems, we collected all of the Pasco data, then all of the FredBot data. FredBot required reprogramming between each run, which signicantly slowed progress. With the Pasco equipment, we collected data on three runs of each type listed above at 10Hz, 20Hz, and 50Hz resolutions, for a total of nine data sets. This frequencies result in a delay between data points of 0.1s, 0.05s, and 0.02s, respectively. With FredBot, the Ping))) sensor triggers after a ve microsecond signal high, releasing a sound pulse, then returns the signal high when the pulse echo hits the sensor. Then, the program converts the time dierence into a position and delays. We ran with the delay at 100ms, 50ms, 25ms, and 10ms to approximate 10Hz, 20Hz, 50Hz and 100Hz cycle times. This resulted in twelve data sets.

Analysis

Presented are the charts generated from the data runs. The raw position data has a few anomalies in the FredBot runs, in particular in the impulse runs, and in one fall run. These are probably due to the experimenters clumsiness, as they all occur as the cart is released. Also note that the data on the stationary cart is somewhat deceiving; all three of the Pasco runs occured with the cart at the same spot, the four FredBot runs occured with the cart in four distinct positions. Despite the anomalies, FredBot succeeded in providing data at a higher resolution than the Pasco sensor. We believe this ability is worth developing further,

and integrating into pedagogical design.

Next steps

There are many possibilities for integrating open source designs in the classroom. FredBot, as it stands, provides one such possibility, but it could be much improved. We could try to develop FredBot into a drop-in replacement for products like Pascos interface boxes. However, this requires development of a signal generator, additional sensors, and a more robust software package. Also, trying for a Pasco workalike probably misses the purpose of open source. Pascos products are eective in the classroom because they facilitate a particular learning style, that which tolerates suspension of disbelief and abstractions. When one can delve completely into the context of physics, its hard to beat their platform. But some students, inevitably, nd the equipment itself more interesting than the content its supposed to teach. Arduino, being an open platform, invites a dierent, more experiential learning style. Those students distracted from physics by gadgets will hopefully nd their perspectives enhanced by seeing exactly how their experiment works. Besides Arduino, other open source platforms are available. Arduino has a thriving user community which shows no sign of slowing down in the near future. The Arduino platform is used by hackers worldwide in everything from quadcopters to automatic gardens. I believe it to be as permanent as Pasco. However, any open platform provides the same basic benets, and most can make use of the same sensor systems. We believe the most useful immediate next step would be exploring alterna2 The analysis given here is rudimentary, and comes with the note that we would gladly work more with the data, given some advice on how to make it useful.

tive sensors in the same or similar lab experiments. For example, accelerometers, commonly deployed in mobile devices have grown highly accurate and robust. These sensors could provide cleaner data, less susceptible to environmentally introduced errors. Alternately, we could focus on developing the ultrasonic system to the standard required currently. As a third possibility, we could pursue alternate open source platforms. Finally, rather than continue developing specic lab components, we could begin equipping the Society of Physics Students chapter with the necessary equipment for developing lab experiments. Experiment development could earn the student money, class credit, or fulll an honors requirement. In summary, our next steps could include: 1. Development using alternate sensors 2. Further development using ultrasonic sensor 3. Development using alternate platforms 4. Organizational development We seek recommendations and advice. Please email any and all thoughts to tabor.hendersongmail.com.

Graphics

10

11

12