Baby Orangutan Precision Timing

Support A-Star and Orangutan
1

Thanks everyone for your help so far. My Mega8 Orangutan is working well with the new Avrisp mkII, and I am very pleased with the MaxBotix sonar. Now I’m getting a little more into unknown (to me) territory, so forgive me if this sounds daft.

I am a mechanical engineering master’s student working at a robotics research lab, and I have recently been shifted onto a new project involving a flying robot (most likely a quad-rotor helicopter). Right now I am the only person working on this project, but we are hoping to stir up interest (funding) with a sort of functional mockup prototype of our concept. That is to say something that doesn’t necessarily fly on its own (although that would be nice), but that demonstrates and validates the electromechanical feasibility of every part of our system design. Then we can hire students from all the other departments to design custom hardware and program it, and show me everything I don’t know about electronics and device interfacing and microcontroller programming (don’t I wish!).

So, my immediate challenge: I need to synchronize two periodic logic pulse signals, from different microcontrollers that aren’t connected in any way. I would love to use Baby Orangutan’s for this, since I have two, and I want to learn to do more with them. In the end my hope is to trigger two MaxBotix sonars simultaneously. One of these sonars will be on the airframe, pointed vaguely down, while the other is on a pan-tilt sensor platform that will be precisely aimed at the first. The sonar on the airframe will receive the pulse from the ground station rather than its own reflected pulse, and send back the range from the ground station over a serial radio.

I have already tested this principle by triggering both sonars together with long wires. The beam is narrow, but if one sonar is well aimed at the other, I can get good readings from some decent ranges and angles up to about 80 degrees off normal. It helps that the pulse is a lot stronger when it hasn’t reflected off of a surface. Another advantage in using two sonars in a straight line is that I double the range, although I halve the resolution…

Anyway, I have a serial radio (LPRS Easy Radio) connected to one of the sonars, and my original thought was to just trigger both sonars with a serial character from one com port with a split line, i.e. going over a wire to one sonar and the serial radio to another. This obviously did not work, because there is about a 19ms delay between the beginning of the packet being sent to the ground radio transceiver, and the beginning of the packet coming out of the remote transceiver (in this time the ultrasonic pulse travels about six and a half meters in this time, I want to keep the added error under an inch!).

My next idea was to artificially match this delay on the ground with one of the Baby O’s (a horrible waste of potential I know, but we will add other functionality to it over time). I wrote some code that waits for an input pin to be brought high, delays using the avr delay.h library, then brings an output pin high. This would be problem-solved, except upon closer inspection (yay for oscilloscopes!) there is a random variability in the signal transmit/receive delay. This variability is small, +/- ~0.19ms, or +/- ~2.5 in but it jumps around that range unpredictably! It isn’t a problem if there is a small range error, or if that error grows over time, but if the range reading is jumping wildly up to five inches all the time it will be much harder to keep the airframe steady.

My professor’s suggestion at our last meeting was to simply (sure) synchronize two microcontrollers shortly before an experiment, and have them trigger the sonars periodically. I modified my simple delay code to loop, brought the reset and ground lines of my two Baby Orangutans together, reset them together, and separated them. Not surprisingly, the ceramic resonators weren’t all that accurate (well with their spec of course), and the periodic signals diverged by the equivalent of about an inch of error each second, but it was a start.

Now, as a mechanical engineer, my first impulse was to go find a more accurate crystal oscillator, do a little fine soldering, and watch my problems disappear. To run a ten minute experiment (about the battery life of our test airframe) with less than 1 inch of range error caused by pulse drift I would need crystals with frequencies accurate to 0.12 ppm. My quick math may be wrong, but I think the order of magnitude is correct, and all the oscillators I’m seeing on Digikey have tolerences of around 20 ppm. Also, articles on AVRFreaks make me think that getting a (non-real-time) crystal oscillator to work with an AVR is not as trivial as plug-and-play.

I still think this can be done with the baby Orangutans, and my oscilloscope tests make me think it might even work with their stock ceramic resonators, by running a real calibration between them at the beginning of each experiment. My level of AVR programming experience consists of copy-pasting C++ code (mostly from this forum) but I think I have a basic understanding of what I need to do.

One Orangutan will be the master, and one will be the slave. I will set a timer on the master O to bring a pin high briefly (30uS or so) five times a second (or so). This pin will eventually be hooked up to one of the sonars, but to start I will connect it to an interrupt pin on the slave O. The first pulse will cause an interrupt on the slave to start its own timer. When the slave is interrupted again ~250ms later the value of its timer will be written to a register. At the third pulse the slave will start its own timer counting repeatedly to the value stored in this register (and disable further interrupts). This timer will now be tied to an output pin on the slave, and I’m ready to go. The master will continue outputting a triggering pulse every 4,000,000 clock cycles, while the slave outputs one every 4,000,001 (or, you know, whatever) cycles. These pulses will of course drift apart, but if I can calibrate them to within a few clock cycles of optimal I think it will work.

In case you couldn’t tell I’ve italicized the words that I think I understand as abstract concepts, but not at all how to implement them in AVR architecture. Of course I’m not asking anyone to whip up a code for me, but more for a few pointers and a general stupidity check:

Is what I’m trying to do even feasible?
Is my current approach correct or flawed?
Am I misunderstanding something fundamental (i.e. “you can’t count that many clock cycles on a single timer”, or “you’ll have to do that in assembly code”)?
Is the hardware of the Baby Orangutan sufficient?

And of course, is there a simpler/better way to achieve my end goal (like “Oh, the Maxstream XBee serial radios have an instentaneous logic pin, plus they cost less!”)?

Thanks for reading this far, I tried to include all the background and reference information I always want when someone asks a short question on the forum that obviously has much wider significance. I wonder if I get the prize for longest (code-less) post?

-Adam

2

Hi Adam,

Could you assign one unit to be a master, and the other to be a slave? The master sends a sonar blip as synchronisation every second. The master and the slave can then send a simultaneous blip half a second later. The MaxBotix data sheet that I found at robotshop.ca/PDF/LV-MaxSonar … asheet.pdf suggests that direct receive data can be found at pin 1 of the LM324 OpAmp. The slave can sync on that.

The actual sync will be dependent on the distance between the master and the slave, due to the delay of sound traveling through air. You could enhance the scheme by having the slave send a response blip back, such that the master now knows how far away the slave is. Make the master blip back once more and the slave now knows as well. You can adjust the simultaneous blip by taking the distance into account.

Hope this helps…

Rob

3

Thanks for pointing that out, I didn’t notice before that the MaxBotix data sheet listed the op-amp chip’s pinout. This will be very useful to me when I start hacking them apart to control them directly.

The problem here is that the sonar on the airframe won’t be aimed in any particular direction, except vaguely down. The sonar on the ground will be aimed at the airframe, and will track it (using machine vision, a whole other can of worms to be opened later). The flying sonar should reliably receive the pulse from the ground sonar, but there is no way to point the flying sonar at the ground sonar to insure its pulse goes straight back.

Our test vehicle is a quad-rotor airframe, which uses fixed pitch blades, so it steers by tilting itself. Aiming the flying sonar would be nice, but it would also add a whole lot of weight and complexity, and our payload with the test vehicle is approximately zero.

I’m not opposed to using the sonars themselves, or anything else for that matter, to communicate some synchronization signal. The only reason this synchronized timing setup sounds good to me right now is that I haven’t discovered that it can’t work yet.
Thanks,

-Adam

4

What’s the ultimate range you need out of the system? If you’re not tied to radio, you can try other means of transmission. Take a look at the gear used by indoor flyers. These days most of the gear I see is radio, but used to be there was a fair bit of IR gear. A sensitive receiver (which you can wire straight in to a pin on the Baby-O) and a nice tight well-aimed beam, and you’d have a pretty fast link with minimal lag. The range isn’t bad. It’s comparable with an IR remote or better (better because at least one manufacturer used to stick eight or more IR LEDs on their transmitter to boost the output power.)

Come to think of it, simply using an IR remote aimed at receivers on the two stations would probably answer quite well. Or gut the remote and have a micro drive the IR LED and signal the two stations simultaneously.

Failing that your idea does look reasonable. But it looks like a lot of work, too. I love building stuff, but I’m also a fan of the cheesy fix that takes less effort.

Tom

5

Good idea! And believe me, Cheesy-Fix is my middle name. Actually it’s Henry. But for example once long (long!) ago I had just signed on to a snake robot project, and I was first learning about micro controllers. I spent two weeks designing and starting to build a system involving two large (14 pin?) logic chips and 16 mechanical relays to physically shift 16 servo controller signal lines one servo over. Then I spent a day reading up on PicC and did it with one line of code instead. Hmm, I have made my share of good cheesy fixes too since then, but anyway…

IR is a good idea, and I may do this as a quick fix for now, but I’m wary to rely on it in the long term. The problem is I have already outfitted the helicopter with very bright IR LEDs in specific positions, which will be used for the visual tracking of the helicopter (using an IR camera, which for now is a webcam with the IR blocking filter replaced with an IR-pass filter). These are very wide angle LED’s for obvious reasons, and to work well the IR photodiode on the helicopter would need to be wide angle as well. The local IR light sources would be much brighter than anything I was shining on it (safely) from meters away, so I don’t think I could do a simple threshold approach.

The final goal is to have this helicopter operate at a range of up to 50 meters from the base station, so we’re probably not even going to use sonar as the final ranging solution, but I suspect we will use synchronized time signals of one sort or another, so from a “functional mockup prototype” point of view, I think I’m stuck doing the timing.

By the way, orangutan-lib rocks, and I’m looking forward to V0.2!

6

Hey, glad you like it! 0.2 should be out in the next few days. I was hoping to get it out earlier, but I came down sick and haven’t been doing as much on it as I’d like.

Yowza! 50m?! Yeah, that’s a little tough to pull with IR, especially if you’re planning to be outside. So yeah, I can see a radio setup would be the way to go. But it does make timing interesting.

Say, here’s an idea: Any chance you could do some sort of a phase locked loop? That can stand some jitter in the signal and still deliver mostly lockstep operation. That plus the delay shift should be more than doable on a Baby-O.

The Wikipedia entry for PLL is pretty good:

en.wikipedia.org/wiki/Phase_locked_loop

If you can have the ground station and the vehicle use the same radio receiver, you may be able to get a decent lock that would take care of the receiver delay as well.

Tom

7

Looks like I’m going to have to replace the ceramic oscillators even if I do frequency calibration! I just did a test today showing that even if I have two timers synchronized as well as they can be in integer number of clock cycles, the frequency drift between my two Baby O’s goes outside my critical 74.7us (the time it takes sound to travel 1 inch) in less than the 10 minute flight time of my helicopter.

I got one really good test where the signal phase wobbled back and forth a few times without going outside the error margin, but right at minute 8 Baby Orangutan #2 took off in one direction and that was that. 2 minutes was a much more common test duration.

My hope now is that with crystals for clocks I can do a one-time manual calibration (cheesey!) rather than figure out how to do this start-of-flight software calibration.

So, has anyone modded a baby O with a crystal yet?

-Adam

8

Keep in mind that Timer2 can be used with a 32768 Hz watch crystal. This would require you to replace the resonator on PB6 and PB7 with the watch crystal and to use the internal calibrated oscillator for the MPU. On the larger Orangutan, this is no problem at all.

I wouldn’t be surprised if this ends up being more accurate than the 20 MHz resonator. You are guaranteed roughly 1 part in 10^5 accuracy using a watch crystal for the timer. If you try it, let us know how it works.

Jim

9

Thanks, I see that in the data sheet now, but I’m a little confused. Is there an advantage (other than that I won’t need load capacitors) to using a watch crystal rather than a 20MHz crystal? Or to using the crystal just for the one timer rather than as the whole system clock?

Hmm, come to think of it, 32KHz would be way slow for the system clock, but if I could use it for the 16 bit timer (timer 1 I think) it would greatly simplify generating pulses a few times a second. On the other hand it would limit my calibration resolution…

I think the solution is to order lots of different crystals to meet the $25 digikey minimum.

-Adam

10

You can have two clocks. The CPU clock would be the calibrated 8MHz internal clock, while Timer2 (not Timer1) would be driven by the cheap (free) watch crystal. You only get 30.5 microsecond resolution from the timer, but it is very stable and accurate.

11

Working on small mobile robots has totally distorted my sense of scale. 2-56 threaded screws seem enormous, and 30.5us is an ETERNITY.

To my surprise my professor has okayed me taking a couple of weeks (spring break is coming up!) to work on this, so I’m in less of a rush and I can actually figure out how to do it right.

I’ll be ordering three or four kinds of clocks in the morning, but a watch crystal doesn’t guarantee me the resolution I need. I think I can build a nice stack of surface mount capacitors and a crystal on the footprint of the original resonator.

I successfully removed the resonator from one of my orangutans today, and I even remembered to switch it over to its internal clock first! I took pictures of the process so I’ll be able to post a how-to when it’s done.

-Adam