System for detecting objects using Arduino

1. Delicately attach header pins to the SRF10, optionally using mounting putty to secure them in place.

2. Insert the rubber grommets into the SRF10 mounting bracket, using a pen if necessary to compress them into a precise circular form.

3. Carefully slide the SRF10 into the rubber grommets.

Secure the SRF10 mounting kit to the servo horn using small screws.

Connect four prototyping cables to the sensor. To prevent them from slipping off during servo panning, secure them with a wire tie.

Avoid screwing the servo horn into the servo for now. The horn fits snugly enough onto the servo without screws, allowing for easy adjustments to the sensor alignment within the roughly 130-degree rotation range of the Pico servo.

Shield Assembly

Arduino shields typically require some degree of assembly. Even pre-built shields often need header pins to be soldered on. Refer to the assembly documentation as necessary.

1. Assemble the ProtoShield by following the instructions available at: http://www.ladyada.net/make/pshield/solder.html.
2. Use double-sided tape to attach the mini breadboard to the ProtoShield.
3. Solder female header pins and speaker connection pins to the VoiceBox shield, which contains the SpeakJet and amplification circuitry. To save space, I used right-angle connectors. Mounting putty is very helpful for holding the components in place while soldering.
4. If desired, place a small jumper between digital pins 0 and 2 to command the SpeakJet using the PheaseALator software.

NOTE: Ensure the female headers are aligned correctly, as misalignment can make stacking the shields difficult.

Arduino Assembly

At this stage, we are ready to stack the shields and start building the prototype.

1. Begin by placing the Arduino on a flat surface.
2. Attach jumper wires to all the ICSP header pins. These will be connected to the XBee shield later. Use zip ties to keep them organized.
3. Insert stackable header pins into the 6 and 8 pin rows. This step is necessary to provide clearance for the jumper wires added earlier.
4. Stack the VoiceBox shield on top of the Arduino.
5. Stack the ProtoShield on top of the VoiceBox shield.
6. Depending on your ProtoShield model, you might find that the pins on top do not align correctly for stacking an additional shield. You can fix this by connecting two stackable headers and carefully bending the pins on one of them to correct the offset.

7. Complete the stack by placing the XBee shield onto the topmost layer of stackable header pins and connecting the wires to the ICSP header on the XBee shield. Using right-angle connectors facilitates quick removal of these connections for USB programming.

Servo Mount

This section allows for creative interpretation, but the following steps outline the design I improvised for this prototype:

1. Insert the rubber grommets included with the servo into their designated mounting slots.
2. Cut a piece of coat hanger to a length of approximately one foot.
3. Using pliers, bend the hanger wire so it fits into the mounting grommets and holds the servo. I discovered that angling it slightly upward helps prevent the SONAR sensor from detecting the ground instead of outward.
4. The ProtoShield and VoiceBox shield have pre-drilled holes for PCB offset pads. Utilize these holes, along with mounting putty or hot glue, to securely attach the servo. Ensuring a stable servo mount is crucial for maintaining accuracy.

Breadboard Detail

This step is optional, but it results in a neater assembly with fewer stray wires that could obstruct the servo’s rotation.

1. Use 90-degree header pins to add connectors for the PIR, servo, and I2C connections.
2. Route the appropriate power, ground, and GPIO pins to each connector using flat jumper wires.
3. Double-check all connections.
4. Verify everything once more and then connect the wires to the header pins. If you have any old computers, you might be able to salvage some lengths of multi-strand wires with pre-attached headers.

5. At this stage, you might want to try breadboarding the XBee wireless programming circuit detailed at: http://www.ladyada.net/make/xbee/arduino.html. Although I didn’t have much success with the XBee shield, it seems feasible, and I plan to revisit this later.

XBee Configuration

The provided link offers a comprehensive tutorial on configuring XBee adapters to communicate with each other. Here are some tips:

1. Connect the XBee Explorer USB to your PC and install FTDI drivers if necessary. Always ensure that you insert the XBee in the correct orientation to avoid damaging it.
2. Utilize the X-CTU tool downloaded from the Digi support site to make the documented changes. I’ve found it helpful to adjust parameters, firmware, and baud rates separately, as the XBee chip can be sensitive otherwise.
3. If you encounter difficulties connecting the tool to the XBee, remain calm. It’s unlikely that you’ve caused any permanent damage through misconfiguration. Verify that the baud rates in X-CTU match those programmed into the XBee. You might have success by enabling API mode and reflashing the firmware. Another method is to short the ground and RST pins to force the XBee to restart. Remember, online resources can be helpful in troubleshooting.
4. The Funnel IO project has released an XBee configuration that functions effectively, provided your XBee chips are running the supported firmware version: http://funnel.cc/Hardware/FIO
5. For wireless programming, it’s preferable to use an XBee Series 1 chip. Series 2 (now 2.5) chips do not support transparent IO line passing, necessary for resetting the Arduino. Alternatively, you can perform the reset in software, but it’s not optimal, as timing it correctly can be challenging.

Functional Testing

Power Issue

After assembling everything, I disconnected the ICSP pins from the XBee shield and proceeded to develop code using USB. However, I observed that the speaker would output gibberish when the servo moved, and the ultrasonic sensor would occasionally crash while attempting to obtain readings. This issue stemmed from the inconsistent power supply provided by the USB connector.

I attempted to address this by using capacitors, but ultimately, the only effective solution I found was to utilize a separate AC transformer during testing. I discovered that a 9V battery is unsuitable for this application. It struggles to supply sufficient current, particularly as its charge diminishes rapidly over time. I intend to conduct further research on battery options and invest in a more robust rechargeable battery kit.

Ultrasonic Sensor Accuracy Issue

Initially, I encountered numerous challenges in obtaining consistent readings from the sensor. To address this, I devised functional tests involving multiple sonar sweeps and calculated the absolute value deltas between them. I recorded these sensor readings and delta calculations in a spreadsheet. Additionally, I conducted a test scenario where I took multiple sensor ranging samples at each step. It was during this process that I observed larger deltas between the first and second ranges compared to those between the second and third readings. Moreover, larger deltas were evident at both ends of the sweep.

The data clearly indicated that insufficient time was allocated for the servo to move. By increasing the delay between readings to allow the servo more time to adjust its position, and by introducing delays at the beginning and end of the sweep, I achieved significantly more reliable results. Furthermore, I observed that reducing the analog gain sensitivity during these tests appeared to mitigate anomalous readings between passes.

SpeakJet Command Issue

This chip exhibited unpredictable behavior, seemingly speaking at random intervals without adherence to commands. It appeared to prioritize event pins over continuous serial commands in its design. I attempted to address this issue by switching to the NewSoftSerial library and breaking sentences into smaller segments, incorporating delays into the routine that transmitted each segment. However, these measures proved ineffective in resolving the issue.

The ultimate resolution, not found in any documentation I came across, involved adding a SpeakJet command to insert a 0 ms pause at the conclusion of every character array before transmitting it to the SpeakJet. This acted as a string terminator, preventing previous commands from randomly overlapping with subsequent ones. It proved to be a straightforward remedy for a vexing issue that took days to unravel.

Table 2: Milestone Chart

Retrospective

I’m pleased with my decision to complete this project using Arduino. It marked my first substantial coding endeavor on this platform, and compared to writing C for the Zilog ZNEO, creating Wiring libraries for Arduino proved to be a more enjoyable and efficient experience. While my time with the ZNEO provided valuable insights into low-level operations, it’s refreshing not to be bogged down by such concerns.

A key takeaway from this project is the finicky nature of sonar technology. Factors like positioning, timing, and environmental conditions can significantly influence readings. I found the performance of the SRF10 in this specific scenario disappointing due to its broad beam pattern, necessitating extensive fine-tuning to achieve accurate readings as the servo rotated.

In hindsight, I might have sought out a sensor with a narrower beam pattern. Integrating an infrared range finder would also have been beneficial, given the relatively long time required to capture ultrasonic range samples. Nonetheless, the broad beam pattern of the SRF10 may still be suitable for stationary installations or situations where the servo’s movement is sporadic, making it a valuable asset for future projects.

One area requiring further attention is the integration of XBee with Arduino. Initially, I acquired Series 2 Pro XBee chips, unaware of their limitations regarding wireless Arduino programming. Upon realizing this, I procured new Series 1 XBee chips. However, I’ve yet to achieve wireless uploading of Arduino sketches, a feature I’m keen to implement.

I believe many of my issues with programming the SpeakJet could have been mitigated by integrating a text-to-speech processor. Consequently, I intend to explore acquiring a TTS256 or similar component and integrating it into the prototype area of the VoiceBox shield.

As mentioned earlier, battery power is another area requiring consideration. A 9V battery proves inadequate for this project’s demands, highlighting the need for a more robust, long-term portable power supply solution, such as a higher-output rechargeable battery.

Attachments

1. Arduino Code
2. Processing Code
3. Hardware Block Diagram
4. Software Block Diagram
5. Process Flowchart

Follow this link for complete project: System for detecting objects using Arduino