PROJECT DATA AND RESEARCH BOOK

An economical solution to researching the future

of wireless Internet technology

 

 

 

Student                                                                                                                      Adult Sponsor

Ken Aycock                                                                                                              Gordon Aycock

 
17 March 2006

 

 

 

 

Table of Contents

 

 

 

 

Intro. 3

Influences. 4

Definitions. 5

Scientific Method. 6

Question. 6

Hypothesis. 6

Problem.. 6

Engineering Goals. 6

Method and Procedure. 7

Materials. 11

Mechanical 11

Hardware. 12

Design. 16

Preliminary Test 16

Conclusion. 16

Prototype I 17

Experiments. 19

Motor Controller 19

The Programs. 20

Conclusion. 22

WiFi Communication. 23

Conclusion. 25

Audio and Video Streaming. 25

Conclusion. 26

Digital Compass. 27

Conclusion. 27

Conclusion. 28

References. 29

Acknowledgments. 30

People. 30

Groups and Organizations. 31


Intro

 

In society today, communication technology plays a major role in changing how our world works. From video conferencing to remote surgery, many new and exciting ideas are unfolding in ways people could have never guessed. The Internet, by far, illustrates the greatest feat of this new age of interconnectivity in which we live. With its power, even Navy crewmen have the opportunity to enroll in online college courses from halfway across the Atlantic. Indeed, the time comes when the obstacles time and space burden us with will be entirely overcome, at least on Earth. Unfortunately, many of these new applications for communication technologies are expensive and thus have not yet reached their full potential to serve the everyday citizen. The goal of my project, then, is to build a machine capable of showing off what the future could hold.

      As mentioned, Internet in particular has revolutionized communication. The biggest complaints about Internet, however, are price, availability, and speed. Many of these grievances may soon be relieved as a project unfolds in San Francisco, California. GoogleNet (unofficial name), a free access wireless Internet system, currently runs in beta testing in parts of the city. Hoping to feed off of localized advertising, GoogleNet has the potential to grow into the next biggest Internet service provider. Not only that, but in the long run it could mean a world where internet access spreads as far as or beyond the reach of cellular phones – and all for free.

      Already most cities are swarmed with wireless access points left freely accessible by the end users, whether intentional or not. The residential areas in Billings are likewise pocketed with these access points. I would like to build an economical robotic rover that could take advantage of (with the homeowner’s permission) such a widespread availability of wireless Internet as there already is today. Utilizing a GPS and a street map system, a robot could be made to travel to different waypoints in which there would be freely available Internet access. At each of these waypoints, the rover could then send back any information desired, and in addition take new commands. With the sensors onboard limited only by the imagination, the project could easily take on new forms with further objectives. I would especially like to incorporate a feedback of pictures and positions, and telepresent operation, or the ability to be controlled remotely and while watching the device on video.

Influences

      Although I had thought of this idea long before I had seen any other applications internet controllable robots, I have since found many websites detailing users’ own projects and their successes. These have influenced my approach at my own project, and are worth mentioning:

 

Kerwin Lumpkins. Telerobotic Tank. 25 Aug. 2005. <http://www.ranchbots.com/mars_rover/rover.htm>

Scott Metoyer. Pedro Telepresent Rover. 12 Sep. 2005. <http://www.potchky.com/pedro/pedro1.htm>

Mark Woehrer. Mac Mini Robot. 9 Sep. 2005. <http://cs.ou.edu/mmr/index.html>

Ed Paradis, Michael Giambalvo. Webplayer-Roomba Integration. 14 Oct. 2005. <http://heathkit.mondrary.com/virgin/>

 

Also; Commercial Wifi Robot at <http://www.robosoft.fr/wifibot.html>.

TOC

Definitions

a.       WiFi Short for ‘wireless fidelity’. A term for certain types of wireless local area networks (WLAN) that use specifications conforming to IEEE 802.11b. WiFi has gained acceptance in many environments as an alternative to a wired LAN. Many airports, hotels, and other services offer public access to WiFi networks so people can log onto the Internet and receive emails on the move. These locations are known as hotspots.

b.      GPSGlobal Positioning System: A worldwide radio-navigation system that was developed by the U.S. Department of Defense. In addition to military purposes it is widely used in marine, terrestrial navigation and location based services.

c.       Telepresence - The remote operation of a robotic system with the aid of an immersive human interface.

d.      PDA - Personal Digital Assistant. Small handheld computer that acts as a personal organizer

e.       Latency - In a network, latency, a synonym for delay, is an expression of how much time it takes for a packet of data to get from one designated point to another. The term is often used to mean any delay or waiting that increases real or perceived response time beyond the response time desired.

f.        Linux - Linux is a UNIX-like operating system that was designed to provide personal computer users a free or very low-cost operating system comparable to traditional and usually more expensive UNIX systems. Linux has a reputation as a very efficient and fast-performing system.

g.       Bluetooth - Bluetooth is a computing and telecommunications industry specification that describes how mobile phones, computers and PDAs can easily interconnect with each other and with home and business phones and computers using a short wireless connection.

 

TOC

Scientific Method

Question

Can a WiFi interfaceable rover capable of telepresent user navigation along with GPS self-guided navigation be constructed on a budget by recycling old or otherwise impaired hardware and materials?

Hypothesis

For under $100, such a rover could be built by using sources such as eBay, online classifieds, and family or friends.

Problem

Materials obtained must be repairable or of high enough specifications to meet the goals of the project. Prototyping may use a considerable amount of funds, but does not necessarily need to be considered as an expense of the final product. All parts and pieces must smoothly work together. If a certain part, once incorporated into the project fails, it too may complicate reaching the goals of this project. More time than is available may be needed.

Engineering Goals

The rover should be:

1)       Maneuverable, light, and powerful. The torque provided to the wheels should be sufficient to move the vehicle on most terrain, extreme cases withheld. The driving motors for the wheels on each side should be independently operable along with speed control. Rover should be able to turn to as little as 20 degrees at a time to correctly orient direction of travel.

2)      Responsive, reliable, safe, and clean. Connection loss should not hinder control of the rover and it should not have the potential of becoming a moving hazard. Components should be safely and securely mounted on board.

3)      Able to travel ¼ kilometer on a single battery charge.

4)      Able to process GPS coordinates and drive to specified locations, ideally other WiFi access points.

5)      Able to relay live video and sound.

6)      Modular. New parts and accessories should be addable without too much of a struggle to allow more possibilities for future components. If done correctly, a modular platform will create an exciting potential for other extensions.

7)      Built for under $100. A budget is important for this project, as part of its purpose is to provide something that could readily be reconstructed by other individuals for their own educational research.

Method and Procedure

First, materials will be acquired and initial designs will be planned. Once construction commences, variables will be tested to determine the best components to use and the most efficient ways to use them. Additional models may need to be built depending on what is found to work well for this project. Data will be kept and notes will be taken during both the construction and the experiments to aid in making the most comprehensive and usable research.

TOC

 

 

Pre-design Research

 

The following minimum materials will be needed to accomplish the goals previously outlined:

1)      A Rover-side WiFi interfaceable computer. This could be any of the following, which each have there own distinct advantages and disadvantages:

                                                               i.      Cell phone – Cost-wise, a cell phone would probably be the most reasonable due to availability. A camera phone could aid in the development of telepresent navigation. Verizon also has Internet service available, as do many other providers. This would also mean the widest range of coverage. Unfortunately, service would need to be purchased, interfaces would be tricky (at best), and communication between the rover and the operating station would be very slow (high latency). The computational power of a cell phone is also low.

                                                             ii.      PDA – PDA’s have reasonable processing power, have many ways to interface, and support multiple operating systems in some cases. Many are WiFi or Bluetooth compatible. These are not extremely available and cannot be easily scavenged. What is available on online auctions and such is too old to be of significant use.

                                                            iii.      Homebrew microchip interface (Atmel / PIC) – Due to the complexity of the project, programming a network of microchips capable of supporting the project would be a daunting task. Data storage would need to be built on catering to the specifications of the microchips as well. Overall, it would take more time than is available.

                                                           iv.      Gumstix Microcomputer – The Gumstix microcomputer is a great robotics tool, with a fully capable 200MHz computer preloaded with Linux and with many adaptations to interface serial devices, WiFi cards, Bluetooth, and more. It is expensive beyond the realm of this project, however. Shown applications include a R.C. Bluetooth operable helicopter.

                                                             v.      Wireless Serial device – A wireless serial device is similar to the Gumstix but has a single output attached to the WiFi capable module. It is cheaper than a Gumstix, but still too expensive for its limited amount of inputs and outputs.

                                                           vi.      Laptop – A laptop would be the optimal choice for this project for many reasons. Above all would be availability, and as a result cost. The potential for use of slower systems is so often underestimated. Many computers determined obsolete can accomplish the regular needs – web browsing, word processing, etc. – with a little optimization. Laptops also have as much or more interfaces than any other piece of hardware. Programming is a breeze as well, in comparison with other platforms.

2)      Camera – The best choice of camera, considering a laptop would be the optimal interface, would be a webcam. These are readily available for under $10 with shipping on online auctions. The Logitech Quickcam is a good candidate, and is Linux compatible as well.

3)      GPS – The cheapest GPS’s found were USB or PS/2 compatible systems. These are very small and consume little power. Most are the size of a portable MP3 player, and have chipset support built into Linux. UPDATE: For around $5, the electronics needed to interface the GPS unit included in all OnStar packages with a computer can be purchased. As many of these units are deactivated, including the one on my parents vehicle, this would be a nearly-free alternative to GPS.

4)      Motors and Batteries – 18v drills are very popular and would include both the batteries and the motors. Wheel chair motors are commonly used in robotics as well, but are less common and more expensive even at pawn shops etcetera

5)      Platform – Most pieces for this portion should be scavengable. Various wheels, sprockets, chains, and even nuts and bolts should be found for free. Lexan would make a great body, but is too expensive for this project. Wood would make the nicest and most manageable structure, but metal will be experimented with.

 

TOC

Materials

Mechanical

1)      (2) 6”  Plastic Wheels - $4.00 Each

Wal-Mart. These wheels are the cheap type intended for use on a push-mower or other lawn equipment. They have very poor traction and are too light to work well with the weight of the entire project. Only used in a failed preliminary design. See fig. 1

2)      (2) 10” Pneumatic Wheels - $4.00 Each

Harbor Freight.  These wheels ran fairly inexpensive but are high quality. They weigh more that would be desired due to their built in bearings and intended use (similar to a dolly), but seem to work well otherwise and will prove to be very durable.

3)      (2) 18v Drill Motors and Batteries – Free and $30.00

Scavenged and Harbor Freight. These motors have a gearbox built into the shaft and a keyless chuck on the end. They are documented in the instruction manual to run ~900 RPM (without major load). Their gear ratio and small size provide just enough power for the project. One was free due to damaged casing and the other was purchased for $30, although similar models can be as low as $20. In the later case the battery may not have equal longevity. 

4)      (2) 36 Tooth Sprockets - Free

Scavenged from old bikes.

5)      (2) 11 Tooth Sprockets - Free

Scavenged from old bikes.

6)      (2) 14” Chain - $3.99 Each

Wal-Mart. Average bicycle chain adjusted to desired length. Also could have been scavenged but were purchased to ensure durability and smooth operation.

7)      Solid Wheel – Free

Shop Scraps. This wheel was found in the shop as a spare unit from an old project. Similar wheels would be found on carts, chairs, or other rolling objects. It can be seen on the front of the preliminary design, Figure 1.

8)      Swivel Wheel - $3.95

Harbor Freight. This solution works nicely with a three-wheeled platform. Easy to attach to any chassis with nuts and bolts.

9)      Camera, digital compass, and microphone mount - $1.75

Ace Hardware. ½” PVC pipe was readily available along with four 45° connectors and two T-shaped joints.

10)  Plexiglas – $5.00

a.      UBC. 1/8” Plexiglas used for the final encasing of the rover

11)  Chassis Assembly – Free

Shop Scraps. Plywood, 1/8” bolts, copper pipe, and other materials. A steel platform was also part of the preliminary design but was far too heavy and very hard to manipulate. See fig. 1

Hardware

1)      Toshiba Satellite 335CDS Laptop (PI) - $10.00 repair

Friend. I received the laptop broken and was told I could keep whether I could fix it or not. At least 7½ years old.

Misc Costs. While attempting to resolve some heating issues with the computer, I managed to lose functionality of the entire motherboard. A generous fellow I encountered online was able to provide me with another for a mere $5 + shipping, for a total of $10.

2)      Compaq Presario (PII) - Free

Brother. The screen seems to have a bad connection somewhere, as it fades out strangely when not properly aligned to the base. This laptop is newer than the Toshiba, but still at least six years old. Was not used other than laptop – to – laptop remote operation due to other hardware issues making the desired wireless cards not function (the PCMCIA slot was unusable)

3)      Logitech Quickcam Express - $8.00

EBay. This was an online purchase for around $5 plus $3 shipping and handling.

4)      Roam About PCMCIA Wireless 802.11b Card – $10.00

EBay. Another $10 online purchase. Has an external antenna jack. Uses the Hermes Chipset as well, making it a good candidate for Linux use. Now works well using the Orinoco drivers.

5)      D-link PCMCIA Wireless 802.11b Card - Free

Brother. My brother had an old laptop that had failed due to water damage. Because his new laptop had a wireless Internet card built in, I was able to take his for free.

6)      Ashton Digital wireless USB adapter - $14.99

                                                               i.      Ebay. This card was found online for a reasonable price. The seller also included information need to interface the card with Linux and the drivers to be used. Because both laptops only had one USB port, and the web cam required USB, this card was bought mainly for testing purposes.

7)      Global Sat BR-305 PS/2 GPS Mouse Receiver – $29.99

EBay. This was a more pricey gamble, and not in my favor as it turned out. Dead on arrival, and I was unable to redeem anything for it. It is now another project to work on. Other cases have been documented online of damage in shipping, but so far I have not been able to isolate the problem with the circuitry.

8)      Dinsmore Digital Compass 1490 – $18.00

Dinsmore Sensors. Online purchase from www.dinsmoresensors.com. The 1490 couples four different hall-effect sensors to read direction. The four sensors are tuned for N, S, E, and W, and are offset by 135°. This gives you eight directions total, with as two can output a signal at once (N+E = northeast). Only accurate to 12° pitch from ground. It is also designed to adjust to swing similar to a liquid filled compass. See fig. 3

 


Figure 1 – Preliminary Design

Figure 2 – General Materials

 

 

Figure 3 – Dinsmore Digital Compass

TOC

 

Design

Preliminary Test

The steel preliminary design was a disaster early on.  Lacking resources, this design was built out of large, thick pieces of steel which needed to be cut down and reformed. Instead of a nice flat base for the other components to be mounted on, the bottom of the rover was a combination of two irregular pieces which needed to be bolted together.

 

After constructing the lower base and mounting the motors with their wheels, a quick test was done to determine whether or not this design was worth pursuing. The test confirmed fears.

 

Max Speed

Acceleration

Turning radius

Weight

0.3 m/s

0.1 m/s2

0.7 m

10 kg

Table 1

                                   

            As the table shows, the metal design was not going to provide any worthwhile results. The speed was comparable to a crawl, and that was when the rover did move. There was plenty of torque to the wheels, as they would spinout and leave a rubber track behind.

 

            Other problems were also encountered with the preliminary model. In this version, the wheels were directly mounted onto the shaft of the motors. This made it hard to squeeze the parts into place and also required that the wheels be securely tied to the shaft under great torque. The wheels would easily loosen any nuts used to hold them in place and did stay in place as they should. Even more disconcerting was that the plastic wheels were not completely rounded and would wobble considerably.

 

Conclusion

 

The preliminary test provided a great guide for the rest of the project. Besides the back wheels being far too small and lacking traction, the front wheel was also a problem. At this point, a single solid roller wheel was mounted far forward. It was clear that a swivel wheel was needed and one was purchased. The next version of the project was decided to be wood based as well. Bigger, pneumatic tires would provide adequate traction. Attaching a sprocket on the shaft of the motor would be much easier to handle under torque and would also allow further gearing down of the drive train system.


Prototype I

This design was intended to answer all of the faults of the previous design and to be approached more carefully with full functionality in mind. All materials used are documented above in the materials section. The drive system was a main concern for this model, and so calculations were made regarding speed and power.

 

Since the previous design had adequate power, it was taken into consideration. To achieve a similar power ratio going from a 6” to a 10” wheel of greater weight, and appropriate gear ratio was determined to be 1:3. Thus sprockets were selected which would most closely fit that ratio. In the end, two 13-tooth sprockets and two 35-tooth sprockets were found and used, which differs from the original ratio by less than 3%.

 

The larger sprockets were welded directly onto the wheels in a safe environment. Copper pipe was available for free, and due to the size of the project it was deemed appropriate for the axle. Since the wheels have built in bearings, they were able to simply be slid on and secured between two washer and two cotter pins. A rectangular platform 0.65 X 0.40 meters was cut out of ¼” plywood. The front was then cut into a triangular shape with a rounded nose. The motors were mounted underneath using bolts and blocking up the gearbox appropriately for their size.

 

After construction of the base model, a fine-tuned CAD (Computer Aided Design) was produced using Rhino 3.0, a software application available for a 30-day trial. The results can be seen in figure 4 below:

 

    Figure 4 – Prototype 1 CAD

Additional designs were drawn incorporating things such as the carriage for the webcam, digital compass, and microphone. Those designs can be found in the Appendix II of this booklet.

 

More data was recorded in comparison with the initial results and are as

follows:

 

Max Speed

Acceleration

Turning radius

Weight

2.74 m/s

----

0.5 m

16 kg

Table 2

 

Weight is still substantial and even slightly exceeds that of the first test. This is, of course, after all elements have been incorporated. Overall it fixed it performed very well and was able to house everything as needed.

 

Tests were done early on in construction and the project has evolved much since then. These results reflect only mechanical achievements, however, and have not changed greatly. Acceleration was not recorded due to overall power.

 

In addition to measuring speed, turning radius, and weight, climbing inclination was tested on the final model. To rate the results, a one-to-ten scale is used whereas a one designates not enough power to begin ascension and a ten means the rover was able to both climb and brake without coasting backwards at said inclination. The results are shown below in table three.

 

14 degrees

18 degrees

26 degrees

37 degrees

10

10

9

7

Table 3

 

The rover was able to handle a steep inclination without difficulty up to around 25 degrees. At this point, after climbing the rover would slightly coast backwards after the climb. At 37 degrees, the rover would climb perfectly, but would then quickly coast down the platform. At no point in the trials was power an issue whatsoever. Figure 5 shows the setup used in the procedure.

 

Figure 5 – Climbing at 26 Degrees

 

TOC

 

Experiments

Motor Controller

As stated in my engineering goals, my motor controller needed to be able to control not only the direction of the motors but also the speed. This would be critical for any fine navigation of the rover.

 

In some systems, a simple potentiometer is used to regulate power output. This could be related to pinching a hose to different levels of restriction – the smaller the inside wall is, the less water is released to the point that no water flows at all. In electrical systems, producing resistance to the flow of electricity creates many unwanted byproducts. Electrical resistance always produces some heat. In high wattage applications, this heat can be so great that it must he dissipated via large metal fins mounted to the electrical components, known as heatsinks. Fortunately, pinching the hose is not the only option in an electrical system.

 

Another method of varying electrical output is pulse width modulation. Pulse width modulation is the process by which the overall power output in a system is regulated by a pulse. This would be like having a valve and pumping it on and off very quickly. The overall water output would be conserved with short pulses at full pressure, as it would flow in spurts. This can similarly be done electrically by at an extremely fast rate. While this may seem a silly and inefficient method to use with water, with electricity it can save substantial amounts of power resulting in a smooth and wide range of control over the drive system.

 

The resulting pulse as explained produces a wave, where a peak is the on time, and a low is the off time. If, over the course of a second, the hose let water flow for half a second and restricted flow for half a second, the result would be something known as a square wave with a 50% duty cycle (the percent describes the time on per pulse-cycle.) A 50% duty cycle is shown in figure 6 below.

 

Figure 6 – 50% Duty Cycle

To get the best results from my motors, I aimed at producing something near 1 kHz, or 1000 cycles per second. In the beginning, I simply used a script that would run a program on the computer turning the electrical switch on and off. This was the absolute slowest approach, and resulted in something more along the lines of 100 Hz. Next, I wrote a series of programs in C with varied outcomes.

 

The Programs

           

My first program in C was similar to my script but with extended functionality. I made the program capable of taking user input to determine the direction of each independent motor along with a number determining the pause. The pulse was produced with a varying sleep() function, which simply pauses for a given time in ms, accurate to about 4-8ms. This program is documented in Appendix I, program A. In testing, this program produces pulses at around 83 Hz.

 

Figure 7 – 50% Duty Cycle – 5ms/division

 

Making each motor run at a different speed was troublesome, as one loop ran continuously in the program turning on and off the signal to the motors. This is as hard to program as it is to manifest physically (try stomping your foot at a rhythm completely different than you pat your head, maybe stomping your foot 5 times every 2 seconds and patting your head exactly three times every 7 seconds). Even more daunting, the program is accessing the same port to execute both speed functions. This would be more like tapping different rhythms out with different fingers on the same hand at the same time. After some attempts at programming this operation, I moved on to be content with each motor operating at the same speed while moving at the same time and at any desired speed independently.

 

Linux is a multitasking operating system as well, making the program run irregularly depending on circumstances such as what other programs are running in the background. When keyboard inputs are pressed, a large gap will be produced in the wave for a short duration.

 

To compensate for these problems, a real time operating system would normally be used. These systems are designed to have hard-coded timing regulations, and are often seen in computers used to control machinery or monitor time dependant variables.

Because Linux has is based on an open source kernel, the “brain” of the operating system, it can have additional modules compiled for many things. Real time modules are available as well, known as RTAI (Real Time Application Interface). However, there is also a function call from within C on Linux systems that will replicate a RTOS (Real Time Operating System). When this module is loaded into the C program, it basically takes full priority over other running processes.

 

Using the RTOS module as described above was tried in an additional C program (see Appendix I, program B). Unfortunately, setting high priorities for the duration of the running program interfered with communication between the rover and the access point, the web cam application, and other running processes on the laptop. In addition, the duty cycle was found not to vary as it would using normal processes as in program A. The average wave produces was similar to that from program A and is shown below at a 50% duty cycle. This was the only wave that could be reliably produced using this program, but its frequency was around 250 Hz as can be seen in *figure 8.

 

Figure 8 – 50% Duty Cycle – 5ms/division

 

Finally, a third program was written and is documented as program C in Appendix I. This program used a different procedure to pause in between pulses. Instead of using the sleep() function, the Linux Guide to I/O demonstrates the use of writing to a dummy port to create very brief pause. This proved to be much more efficient, and in testing produced a frequency of around 850 Hz.

 

Figure 9 – 50% Duty Cycle – 5ms/division

The program’s user interface was also significantly improved using the ncurses library to allow keyboard input to change both the speed and direction of the rover while running.

 

Conclusion

           

Using the sleep() function, it was possible to create a pulse that would run the motors but not as smoothly and effectively as desired. The program was also susceptible to interrupts from Linux, being multitasking operating system. Using RTOS modules in C, the pulse could be controlled without being effected by outside influences but also was not completely perfected and resulted in being unable to vary the duty cycle, along with a still unacceptable performance in frequency.

           

The winning choice of creating a PWM signal was to use port writes to a dummy port, namely 0x80, as described above and used in program C. This produced a desirably frequency without interrupting other processes running on the laptop and creating problems with communication.

 

I was unable to pinpoint other oddities in the wave when approaching a very high or very low duty cycle. At these ranges, the program would need to switch the motor signal on and off successively very fast, which would understandably create difficulties. Figure 10 is provided as an example, running at a 99% duty cycle (nearly full speed). Notice the strange pattern the wave makes.

 

Figure 10 – 99% Duty Cycle

 

Currently, program C runs the rover for all testing and operation. In the future, a true RTOS may be investigated which will appropriately control the motor speed in a time demanding environment.

 

*Note: Figures 8 – 10 were all created using a free program called “Oscilloscope for Windows.” This program uses the computers sound card to register changes in charge on a connected cable exactly the same way that sound waves are often graphically represented in audio applications or sound recorders. Since sound requires accuracy to a high frequency in order to attain quality, with many sound cards sampling at as high as 20 kHz, the microphone input was reasonably utilized to record my experiment results.

WiFi Communication

 

Knowing what wireless components would return the best performance in range was important while choosing wireless hardware for the rover. The hardware needed to be able to reach 100ft or more from the source controlling it and also needed to be reliable and responsive.

 

WiFi interface of the rover to another wireless device was tested for distance with three different wireless Internet cards available, all using standard 802.11b protocol. To test distance, both the connections from card-to-card, known as ad-hoc, and the connection from card-to-access point (wireless router) were observed.

 

Measurements were taken for both the range required to pick up a reading of the alternate wireless device and the distance required to actually communicate with the other wireless device. These values should be different, as a connection will only be made when signal received is within a certain threshold. Table 3 shows the recorded results. In the tests, the Compaq laptop had the Ashton Digital wireless Internet card attached for the entire process while the Toshiba used both the D-Link and the Roam About cards. Unfortunately, the testing area could only accommodate a total range of about 100m. The first test attempted to pick up the unique signal broadcast by the Compaq laptop for maximum distance. A program called Kismet was used in these tests. Kismet “sniffs” out data in the 2.4Ghz range and then interprets what it received. In an area with no connections, Kismet would return only noise and would not record any readings. In an area with an access point, it will return packets received as they come. At the location used for testing, about 10 different access points were discovered in addition to the Compaq laptop intended for use in the test. This did not appear to effect test data, however, and since the Compaq access point (the compact card was placed into ad-hoc mode) had a unique name, there was no worry of mistaking the transmission source.

           

Distance

D-Link

Roam About

10m

4 pkts/s

4 pkts/s

25m

4 pkts/s

4 pkts/s

50m

3 pkts/s

2 pkts/s

75m

1 pkts/s

1 pkts/s

100m

1 pkts/s

0.5 pkts/s

Table 3 – Packets per second received

 

These values were averages over a duration of time since about 5 packets are received at once. Both performed similarly well in this test and only the frequency of packets received changed with distance. At no point was the access point completely undetected. Knowing this, I hypothesized that both cards would also be able to receive transmission of actual data for the full span of the 100m.

Next, the both laptops were configured for ad-hoc mode. The ping command, which simply requests a reply from the other computer and measures the time it takes for the response to arrive, was used for both wireless cards. The results are shown in table 4.

 

Distance

D-Link

Roam About

10m

4.02ms

4.22ms

25m

16.34ms

12.49ms

50m

7.61ms

4.01ms

75m

4.76ms

5.31ms

100m

8.45ms

5.67ms

Table 4 – Time required for response

 

In further observations, the distance of 25m repeatedly created a slight peak in latency and at times no response was seen. On one pass, the connection even needed to reset before continuing. This was often due to some outside noise factor. Many things can cause such noise. For instance, microwave ovens operate at a frequency very near that of 802.11b/g wireless components. Figure 11 below shows the testing area.

 

Figure 11 – WiFi Distance Test

 

Conclusion

Goals were met, as it was deduced that wireless connections with the current components were usable well with the 100ft aim. Due to time restrictions and lack of other areas to experiment, a full analysis of the distance capabilities of the wireless components could not be performed at this time but would be a great place to start as a continuation of this projects research.

 

Because the wireless cards performed equally well under testing, other factors determined which wireless card would be used. Among other things, the D-Link card worked more easily with Linux due to slight differences in internal design. Even though the same drivers are used, different versions of firmware, or the programming hard-coded into the wireless cards instruction chips, caused different responses to running a computer-to-computer interface. The D-Link card was also assumed to have a slight edge over the other card due to overall experience, but this gesture cannot be confirmed at this time.

 

The experiments, although overall not providing an entirely complete analysis, did provide valuable insight into the wireless aspects of this project. While logging detection data, numerous wireless access points were discovered. Having previously surveyed our area for such presence, it was clear that wireless internet technology has expanded at an astounding rate. At one point while using the Compaq laptop, Windows XP even automatically established a connection to one of these access points and Internet access was acquired without any intention of the end user. 

 

Future tests may not be practical in the future using the components as stated. Soon, the release of a new wireless Internet standards such as WiMAX and 802.11N will outperform old technologies and at similar costs. Instead of further investigating performance of b/g band wireless connections, research into these new standards would be far more interesting, rewarding, and practical.

Audio and Video Streaming

Video streaming was desired for the capability of telepresence, or the state of seeing a remote location and controlling an environment from a different location than is being observed. Audio was also a thought, but until the ease of addition implementation was realized was not a strict goal of the project. In that aspect, these experiments exceeded the hopes of the initial image.

 

The streaming of video with a webcam was previously done with a simple web-based interface in which jpeg compressed images were written to the same file repeatedly at a maximum rate of ~3/second within a publicly accessible folder. This was prior to the projects official origin, and was a personal endeavor.

 

This setup was tried for the rover for a short time. The software showed strange behavior while interfacing with the user, however. After a certain amount of time, an error would always occur which would render the webcam feed unusable until the program could be reset. This program is included in most Linux distributions and is simply called “webcam”. The fault was found to lie in the communication with the driver and not the actual program itself.

 

Through further research, an alternative streaming application was found called “palantir”, named after a crystal-ball like object found in J.R.R. Tolkien’s series The Lord of the Rings. This program, in addition to providing more reliable video stream, also included a layer for audio interface as well as controls for brightness, contrast, and etcetera. It even had extensions available meant for implementation of a pan-tilt apparatus, but this avenue was not further researched. It was well noted for future developments, however. Clients programs were available in both Windows and Linux operating systems.

 

In testing, the frames / second ranged from about 4 to 8. Range was the main limiting factor in the throughput of this data, although another issue caused the frame rate to stay below 4 / second depending on configuration. The exact cause of the issue, after a long survey of conditions, was unable to be identified. It was however noted that when the motor controller program was initialized the frame rate would eventually reach its higher threshold and performance improved. Table 5 below shows some of the results in different tests. They were taken at intervals of 30 seconds, with the rate reported from palantir:

 

Slow Rates at Range

Otherwise Slow Rates

Peak Performance

3.77f/s

4.13f/s

7.94f/s

4.02f/s

4.01f/s

7.34f/s

3.56f/s

3.42f/s

6.50f/s

3.64f/s

3.66f/s

7.85f/s

3.80f/s

4.01f/s

7.78f/s

Table 5 – Recorded Webcam Frame Rates

 

Sound was also transmitted as described. The sampling rate can be modified, which will impact the quality of the audio. 16kb/s was the only tested rate, however, and this is another avenue for future investigation.

 

Conclusion

Palantir proved to be a great and reliable way to implement streaming video and audio into my project. While another program was tested, namely “webcam,” its use was deemed impractical and its design an inappropriate strategy to achieve the intents of the project.

 

Palantir was also another free way to expand the functionality of the project. In addition, it was found to be very usable on both Linux and Windows systems, ideal for communication between the user and the rover as Windows holds a much stronger presence on personal computers.

Digital Compass

The most recent addition to the project was the digital compass. A digital compass is important for any GPS automation because the standard and inexpensive GPS determines coordinate headings on simply the movement from one location to another. If one is to hold a GPS designed this way and change headings by pivoting on a point, then, the reading will not change and the last direction of travel will still be recognized instead of the true and accurate heading.

 

The Dinsmore 1490 was found to be the most sound solution, as it is simple and uses only the four major cardinal directions for collecting data. With each sensor offset by 135 degrees, there are a total of 8 different actual readings. Some of these readings are overlaps whereas both the north and the west sensor, for instance, would send a signal back to the user. In this case, the program would need to interpret the reading as northwest.

 

In testing the 1490 performed well but was found to be delicate. The datasheet provided by Dinsmore indicated that it would only return an accurate reading within a horizontal tilt of 12 degrees. This required careful adjustment but was not a difficult problem to overcome. The compass also needed to be mounted away from the motors as to avoid magnetic interference. For this reason, the compass (left) was mounted near the camera. This can be seen in figure 12.

 

Figure 12 – Digital Compass Mount

 

After calibration and accurate readings were assured within the 45 degree radius each reading would be within (8 readings in a full circle = 360/8 = 45 degrees per reading) no further testing was done.

 

Conclusion

This component performed as needed for the project but would need further experimentation to explore its full potential. Using the digital compass alone, simple orienteering could be done. If distances could be accurately measure by duration of running motor time, for instance 1 second at full speed on carpet = 3 meters, complicated paths of travel could be attempted in through an automized system.

 

 

TOC

 

Conclusion

The project was definitely a success. The engineering goals, excluding autonomous operation, were well met and provide a great insight into the future and current applications of wireless Internet technologies.

 

The project budget was exceeded slightly by $2.68, which under the circumstances, seems acceptable. It was not immediately obvious that a digital compass would be needed for autonomous operation which would alter the overall costs by enough of a margin that a GPS could be additionally added still closely within the defined budget. Realistically, GPS operation would require a budget inflated to at least $130 or so with a digital compass.

 

Other problems arose during the course of the development of the WiFi rover not originally expected. The motherboard failing (which occurred in early December) nearly devastated the project but in the end this obstacle was overcome. The GPS arriving broken was also an unexpected problem that caused some problems but had no direct impact in the final research, as its costs were not included in the rover budget since it was not used.

 

The experiments were successful. Through analyzing different strategies to controlling the motors, an acceptable interface was created that was very cost efficient and worked better than expected. Much was learned in researching Linux’s inner workings with the hardware, and new ideas were inspired through the process. The project now has many different options which could be tested for the absolute best and most reliable solution for interfacing the motors (and other sensors) such as a Real Time Operating System. All other experiments, such as the audio and video streaming, were also deemed worthwhile.

 

As the project still holds many open doors for research, it is even more exciting that this project could be recreated by other interested scientists around the world. I hope that by making this information available in a detailed format that I can spark interest in motivated students and professors alike and help others experience the joy of science and engineering.

 

 

 

TOC

References

 

 

Dinsmore Sensors. “Digital / Analog Compass Sensors.” February 2006.

            <http://www.dinsmoresensors.com/>

Ebay. “Ebay online auctions: Whatever it is, you can get it here.” 2005.

<http://www.ebay.com/>.

Google Web Search Features. “Google Definitions.” 2005.

<http://www.google.com/intl/en/help/features.html#definitions>.

Gumstix. “Gumstix: All small things.” 2004.

<http://www.gumstix.com/>.

Kismet. “Wireless network detector, sniffer, and intrusion detection system.” 2005.

<http://www.kismetwireless.net/>.

Oscilloscope for Windows. “Digital Oscilloscope Uses PC Sound Card for Input.”

<http://polly.phys.msu.ru/~zeld/oscill.html>.

Verizon Wireless. “Broadband Access.” 2005.

<http://www.verizonwireless.com/b2c/mobileoptions/broadband/index.jsp?action=broadbandAccess/>.

 

TOC


Acknowledgments

Many people deserve recognition for their help, support, and guidance. Also, many groups in the Linux community made it possible to put together the software necessary for the construction of this project under the goals defined. This list will be as complete as possible, but if anyone is left out, please forgive me. There is not any particular order in which these acknowledgments are listed. Links will also be provided where appropriate in the groups portion and are dated according to discovery.

People

- Special Thanks to: -

 

Gordon Aycock – Adult Sponsor

Ruby Aycock – Editing and Display Support

Rich McFate – High School Teacher and Advisor

Dr. Mark Jacobson – EE and Math professor

Gayle Wittenburg – Logistical Consultation

 

 

- Also: -

 

Nikola Tesla

Linus Torvalds

Mr. Don Kaul

Patrick Volkerding

Riku Saikkonen

Leah Hess

Woody Sukut

Jon Light

Shawn Leavell

Mrs. Cerise

Sam Schrock

Groups and Organizations

Apache. “HTTP Server Project.” 2005.

<http://httpd.apache.org/>.

Palantir. “A multichannel interactive streaming solution.” 15 January 2006.

<http://www.fastpath.it/products/palantir/>.

High Voltage Community. “Forums.” 2004.

<http://4hv.org/e107_plugins/forum/forum.php>.

Slackware Linux. “The Slackware Linux Project.” 2004.

<http://www.slackware.com/>.

OpenSSH. “Keeping your communiques secret.” 2005.

<http://www.openssh.com/>.

GNU Compiler Collection. “GCC – A Free Software Foundation.” 2005.

<http://gcc.gnu.org/>.

Linux I/O port programming.  “Mini-howto.” November 2005. 

<http://www.tldp.org/HOWTO/IO-Port-Programming.html>.

Quickcam Express Development. “Logitech Quickcam Express Drivers.” 2005.

<http://qce-ga.sourceforge.net/>.

 

TOC