Orangutan resetting when a distance sensor is connected

Support A-Star and Orangutan
1

I’ve been chugging merrily along with programming the Orangutan. But today I tried to hook up my first sensor, and it’s the darndest thing – whenever it’s connected, the program seems to continually reset and start over.

The sensor is a Sharp GP2Y0A21, which has three pins: Ground, Vcc, and Vout. I’ve double-checked the datasheet, and confirmed that I have Ground connected to the outermost row on the Orangutan’s ADC6; Vcc connected to the middle row; and Vout connected to the top row.

When the sensor is not connected, my program works fine: it displays a greeting, beeps once per second or so until I press PB0, does a quick buzzer slide, and then goes into a loop where it reports the 10-bit value read on AD6. Of course with the sensor unplugged, this value is always 0.

When the sensor is connected, two things are different. First, my once-per-second beep (a simple call to buzzer(440, 200)) has become a much more complex tone. Second, every second or two, the program resets and starts over from the beginning. So if I push the button to put it into sensor-reporting mode, it does briefly report sensor values — they even look like reasonable numbers (varying between 200 and 500, but I haven’t played with the sensor much yet). But then it quickly goes back to start of the program.

Could it be a problem in my code? I’m calling analog_init() near the top of main(), and I read the sensor by a macro defined as (analog10(6)). The loop where the reset occurs is just:

	int lastDist = -1;
	for (;;) {
		int curDist = FRONTDISTANCE;
		if (curDist != lastDist) {
			lcd_gotoxy(0,1);
			lcd_int( curDist);
			lastDist = curDist;
		}
	}

It feels like a hardware problem to me, but this same sensor worked fine on my ARMmite board, and it’s about as simple as an analog sensor can get — it just returns a voltage between 0 and Vcc on Vout. Any idea what’s going wrong?

Thanks,
— Joe

2

Here’s another clue, perhaps: when I unplug the AVRISP(mkII) header, the resets no longer occur. However, the beep during the greeting wait-loop still sounds different, and this makes me nervous. With the sensor unplugged, I get a nice pure tone. But with it plugged in, I get a complex sound, something like a chord. Here’s the loop involved at that point:

	while (not done) {
		// beep
		buzzer(440, 200);
		// twiddle our thumbs for 2 seconds at a time, or till button 0 is pushed
		for (unsigned int cycles=0; cycles < 2*40; cycles++) {
			_delay_ms(25);
			if (BUTTON_PIN & (1 << BUTTON0)) {
				done = true;
				break;
			}
		}
	}

Apart from the strange sound, the program appears to work OK with the sensor when the ISP cable’s unplugged. But clearly the behavior’s not the same, and I’d like to understand why. Also, the ISP cable has never made a difference before; why is it causing resets in conjunction with the sensor?

Thanks,
— Joe

3

I also had issues running several AVRs (aside from the Baby-O and the O) with the ISP header still connected to an AVR ISP mkII. I am now disconnecting the ISP header after I program the AVR.

Based on Atmel documentation, the mkII (and any ISP programmer) should be able control the reset, it is a requirement for ISP programming, though I’m still not sure why the RESET occurs even when not in programming mode.

4

Any flickering on the LCD during all this?

I don’t know what your power supply is like, but this is one I’ve done to myself a couple of times: The LCD draws a fair bit. Sensors can draw a fair bit (those Sharp sensors aren’t the lightest weight thing in the world, though I haven’t hooked any to my Orangutan yet). The regulator on the Orangutan can handle a fair bit (100mA) but if you’re running off batteries, depending on how much charge they’ve got, a sudden spike in draw can dip the Orangutan and cause problems.

I’ve usually had the LCD dim out well before I get a reset, though. I’ve also run into odd inconsistencies in behavior when the ISP cable is plugged in and when it isn’t. Unfortunately I didn’t document them, just checked my batteries, made some “WOW that’s low!” sound, and changed them out.

Not saying that’s what’s happening here, just one more thing to check.

Another one to check is how noisy those sensors are, and more important, how much noise they cause on the power and ground lines. Might need some filtering. But if I remember right they’re not supposed to be that noisy. I’ve never filtered them when I’ve used them.

I’m guessing the bank you’ve got them plugged into is jumpered for Vcc and not Vbatt?

Tom

5

I have weird problems with my AVRISP, it occasionally resets my MCUs for no good reason (like after 10 minutes). It also seems to conflict with the Pololu USB to Serial adapter. If I have both plugged in for more than about a minute they both go dead, then only the programmer comes back (until I reboot my computer). Anyway, this probably isn’t related to your problem, but I don’t trust the AVRISP MKII!

Anyway, those sharp sensors can draw a hefty 30-40 mA, which shouldn’t be a problem if the only other thing you’re running on the Orangutan is the LCD, so long as your batteries are nice and charged!

-Adam

6

I haven’t noticed any dimming or flickering of the LCD during this. The batteries are seven AA NiMH’s, currently measuring 8.9V. That’s not a fresh charge — I’ll try recharging them this morning and see if the problem goes away.

As for jumpers, this is ADC6, which if I understand the QuickStart correctly, is always provided Vcc power. I’ve measured 4.83V between the power and ground pins on this port (and somewhere around 1.3V, depending on what’s near the sensor, on the signal pin).

So, I’ll suspect some combination of AVRISP MKII causing weird problems, and the sensor drawing too much power for my current battery charge. Hmm, come to think of it, the buzzer must draw a fair amount of current too – maybe it’s not outrageous to suppose that with the LCD and sensor both drawing power, there’s just barely enough current to run the buzzer too, causing current dips which distort the sound, resulting in the strange tones I hear when the sensor’s plugged in.

If true, it should go away when the batteries are fresh — and this will provide a nice audio cue for when my batteries are getting too low!

Thanks,
— Joe

7

A suggestion from one of the guys in my local robotics club turned out to be the right answer: those Sharp distance sensors actually are quite noisy, and it was causing spikes on the Vcc line.

This was pretty neatly demonstrated via the “weird beep” problem. Turn the device on (with sensor plugged in but no filtering), and the beeps sound thick. Touch a 220uF capacitor to the power/ground leads of the sensor (or stuff it into PC4, right next to ADC6), and suddenly the beeps are pure and clear. Pull the capacitor back out, and the beeps get thick again.

If the sensor was causing enough noise on Vcc to be audible over the buzzer, I’m quite willing to believe that it was causing the resets too (in conjunction with the ISP — still not sure why that made it worse, but it could be just a matter of drawing more current in conjunction with the spikes).

Lessons learned:

  1. Sensors can be noisy, and if the device gets flaky when the sensor’s plugged in, start thinking capacitors.

  2. Having repeated, simple beeps in the greeting phase of your program is a great way to immediately know when something is funky with the power supply!

Cheers,
— Joe

8

WHOA! Good to know! I was about to put two of these into service on a Baby-O project, so I’ll go ahead nad add the 220uF caps. Thanks!

Come to think of it, someone else in our local club is already using some on his Baby-O, so he’d benefit from this as well. I’ll forward it on.

Tom

9

Hi, All,

I’m a bit late to the discussion, but just to add to Joe’s lessons learned:

“Sensors can be noisy” is a bit misleading since that type of statement usually refers to the output of the sensor, i.e. the sensor reading. (Also, I would replace “can be” with “are”.) You’ll probably want to process your sensor output to deal with the noise; you can do that with hardware and software methods (e.g. simple rc filters, averaging ADC samples).

To the extent that sensors can demand a lot of a power supply, that is generally true of anything you attach to your power lines. The broader lesson is that you cannot just attach everything to a 5V line and expect it to stay at 5V. Average current consumption is a starting point, but 1A pulses with a 5% duty cycle are very different to your power supply than a constant 50 mA. In the case of the distance sensors, the output is updated at around 25 Hz, and the LEDs are probably pulsed every time a new measurement is made. Especially if you have multiple units, you could get some big current spikes if they happen to pulse the LEDs at the same time.

- Jan

10

That reminds me of something I was wondering: is there any easy way with an Orangutan to turn sensors like these on and off as needed? I’m guessing not – the power and ground lines on the 12 I/O ports are just busses. Well, the power one is actually three separate busses, but even if I did something clever with the jumpers on the two selectable ones, at most I’d be able to turn on and off two banks of them, right?

For this robot I was planning to have about eight of these sensors. But now that I’ve seen their behavior, I worry about the amount of current their going to draw. (I don’t worry so much about the pulses, since now that I’m aware of it I should be able to smooth that out with capacitors.) I wish I could just turn one of them on, take a reading, and then shut it off again, so only one is powered up at a time.

I suppose that would take some sort of daughter board… a sort of multiplexer for powered analog inputs. As a bonus, such a multiplexer would let you get by with a single A/D input on your main controller. Hey Jan, there’s another product idea! :smiley:

Best,
- Joe

11

You can get a multiplexed A to D converter on a chip(Digikey has a whole catagory devoted to them, if you search for “A/D Converters (A-D)”), but I actually don’t know of any with just an analog output.

What if you connected wired all your analog sensor signal lines (maybe through small diodes if necessary, but I don’t imagine it would be) into one analog input, then used transistors connected to general IO lines to switch power on to the sensors one at a time? I can imagine tis as a daughter board, or just as some transistors and wires pressed into the IO receptacle.

Since sensor power is becoming a consideration, I’m starting to think about how to kludge (nicely) another voltage regulator or two onto my Orangutan to power the selectable blocks of IO headers. Maybe one 5V and one 3.3V.

-Adam

12

Just to throw something in here, I used 4 GP2D120’s and 4 QRD1113 sensors with an Orangutan. The original plan was to power everything off VCC and I found as others did, that it was too much for the regulator (yes the LCD blanked out). Since I use a 6 volt battery, I moved the GP2D120’s to VBAT (these sensors can run on 7 volts) and left the QRD1113 sensors wired to VCC.