This year we decided to offload the gyro integration to save bandwidth in the robot controller. We built a pretty simple board using a STAMP 2sx, an ADC and a DAC to sample the gyro, integrate it, and report the resulting bearing back to the robot controller.
Considering the whole thing could have been done better for a fraction of the cost, I’d like to get some experience with the PIC series controllers. They seem well suited to the sort of slave parallel processing tasks we’d like to implement.
Anyways, I need a programmer and figured the PICStart II is the way to go. Can anyone with some experience confirm or suggest an alternative? Thanks
I’ve used the PICStart Plus quite a bit - it’s $200 from digikey, but it’s been out long enough that you might be able to find one on ebay. Lately I’ve used the PIC-ICD quite a bit - you can get it for $100, but it’s more complicated to use, and it only works with the 16F87x chips. But it lets you pause and debug programs on the chip in the circuit, which is a really neat feature.
If you can afford it, the PICStart Plus is probably the way to go. It’s well integrated with the MPLab software and it’s really easy to use.
If not, I’ve also used the EPIC programmer here: http://www.melabs.com/products/epic.htm
It uses the parallel port, isn’t integrated with MPLAB, and for some reason, I was unable to run it under Windows NT, but once I got it working, it was very solid, and it let me do in-circuit serial programming, and it’s only $60.
There are also plans all over the web for different kinds of programmers, just ask the goog
The PICstartPlus package is excellent. I got one several years ago, and cant say enough good things about MicroChip, their uPs, their tools.
It amazing what you can do with their uPs. From the little 8 pin ones, up to the 40 pin DIPs. If anything, they are a little more expensive than other microcontrollers, but if you are building small quanitiies of stuff, the ease of use is worth the few extra dollars.
BTW - I went to Dean Kamens house during the kickoff a few years back, and smiled when I saw the PIC box on a shelf in his library :c)
We had thought about doing an external circuit to turn the Gyro into an absolute heading signal, and realized all you have to do is accumulate the output value (normalize it by subtracting 127) in a 16bit variable - just add it on every loop, and if deltaT is = 1, add it again.
Since the loop in your SW is running at a (deterministic) fixed rate - by accumulating it in a 16bit variable, you are in effect multiplying the degrees/second signal by the cycle period (seconds) and you end up with a 16bit value that is directly proportional to the number of degrees the robot has turned since you powered it up.
We us it in our code to determine when we have turned 45° in auton mode - 45° comes out to be around 3000.
Thanks for the information.
For one or two turns you can add up the magnitude and get repeatable results, but when we tried to do it over 15 seconds there was too much drift. One of the programs is set up to drive laterally across the field looking for bins using an IR ranger. When it sees one it turns 90 degrees, drives forward to push it out of the scoring zone, then reverses, turns 90 degress to rejoin the search path. The robot could only make maybe 2 transitions before it drifted so much it was useless.
We had a couple of different programs that used the bearing so it cut down on maintenance by providing the value directly to the robot. It provided some flexibility when they put the robot on the field because they didn’t have to get the angle perfect, just put it down square, reset the bearing, and rotate it in place. It will still steer to the correct angle no matter which direction its pointed.
I think it worked well, and they can add the bearing to any program by just plugging in the board. Theres a video on www.soap108.com of match 91 at Chesapeake that shows the robot slip on the ramp, sense that its off course, correct itself, and hit the stack. We were slow but reliable, like everyone we just needed a little more time.
*Originally posted by seanwitte *
**Thanks for the information.
For one or two turns you can add up the magnitude and get repeatable results, but when we tried to do it over 15 seconds there was too much drift. One of the programs is set up to drive laterally across the field looking for bins using an IR ranger. When it sees one it turns 90 degrees, drives forward to push it out of the scoring zone, then reverses, turns 90 degress to rejoin the search path. The robot could only make maybe 2 transitions before it drifted so much it was useless.**
One thing I had to watch for was the offset of the gyo output was not 127 as commonly assumed, but closer to 128. Thus, you would have a less-than-one-degree/sec turn to the right added to the robots position.
It might be fun to put the gyro through an op-amp low-pass filter with an adjustment for the offset that has an even lower pass filter, an arrangement that would put an end to the ceaseless digital filtering schemes.
a simple way to solve the gyro ‘zero’ problem, when you first start auton mode, read the gyro and see what its putting out. Since the bot is not moving, THAT is your zero reading.
subtract that from all subsequent readings - and it wouldnt hurt to ignore any outputs that are +/- 1 or 2 counts from that as well - its very unlikely that your robot would ever be turning that slow.
Then you should be able to use the output over a longer period of time.
Also - make sure your gyro is firmly mounted to the most solid part of the chassis, thats its perfectly flat on its plane of rotation, and that its as low on the robot as possible.
dont forget to check delta_t when integrating the gyro output - if delta_t is not zero, you have to account for the additional time (add the gyro output to the integration for each count of delta_t)
also- make sure when you turn, you do not turn faster than the 75°/ S rate
*Originally posted by KenWittlief *
**a simple way to solve the gyro ‘zero’ problem, when you first start auton mode, read the gyro and see what its putting out. Since the bot is not moving, THAT is your zero reading.
**
With 6 motors drive, and three other feedback systems, and the autonomous mode variables, the number of spare variables available got pretty limited. I set the gyro iniatial value as a program constant, and got reasonably consistent turning results. It was during driving that we had trouble, which turned out to be ‘wheels not mounted perpendicular to the side of the robot’ problems, but this was not apparent until after we’d tossed out using the gyro, and gone to much more reliable (with straight wheels) timed turning.
On the other hand, since the gyro seems stable enough when not moving, the op-amp solution could be set-it-and-forget-it. It requires no programming space, outside of accumulating turn rate info. You could do that with a (really) low leakage integrator. If you made the output voltage range 127+/- 90 counts, each count = 2 degrees, and you’d have turn rate if you needed it, or heading data right there. Rollover at 0 or 360 would require some relay work,
Note that Systron Donner’s webpage offers big boxes with 3 axis turn rates and accelerometers - the complete inertial nav system. But they probably do it digitally to make reprogramming easy, in the meagabytes of fast, powerful computing space they use. 
I use a PICStart, btw, and endorse it heartily, although Microchip is pushing the IDC2 to be able to use its extra features.
I’m going to get the IDC2. It supports the chip series I’m interested in plus the debugging feature.
I bought a pretty cool little gyro from Analog Devices called the ADXRS150. I haven’t had time to really do anything with it yet, but it looks good on paper. Low noise angular velocity up to 150 degrees per second. The ADXRS300 goes up to 300 degrees per second, but I wasn’t able to find the evaluation board for it. The evaluation board has all of the support caps and the gyro soldered to a tiny PCB that can be plugged into a regular DIP socket. The package itself is a BGA, there no way I’d be able to solder that.
I also got some free samples of the '150 series accellerometers. I was planning on using it as a gravity-based tilt sensor. Has anyone successfully used one to measure distance?