Interfacing a digital compass with the RC

[Dave Flowerday]

Originally Posted by Al Skierkiewicz

The I2C reference is a car serial control protocol as I remember.

You're probably thinking of CAN. I2C a very short range, low speed serial interface and designed to be a simple interface between microprocessors/microcontrollers and various peripherals. The uses of I2C are basically the same as SPI - in some ways they could be considered to be competing standards (though many microcontrollers will support both interfaces). It is typically used to connect chips that are all on the same PCB, and isn't that hard to implement in software if necessary.

Originally Posted by Al Skierkiewicz

FYI so you don't get too discouraged, we spent some long hours trying to debug the compass while working on a stainless steel conference room table. Rack that up to late hours at the end of the build. It took us a while to realize where the error was coming from.

Al, I'm going to step in here and defend the team that worked on this. Nate and the rest of the firmware team explored the compass as one possible solution to determining orientation, and we all knew that the room we were working in wasn't a good location to test in. We never wasted long hours trying to figure anything like that out. We tested it in many locations, including at our field and in the model shop. The bottom line is that the compass we were using at the time (can't remember the model #) was totally ineffective. When installed on the robot it didn't report anything useful at all (the readings would change with fluctuations in motor speed, which is what we were afraid of). Adjusting the reading with the high-current pulse or whatever method that one used wouldn't have made any difference (the compass we were using was not I2C - as I recall it output an analog signal).

The year this took place was 2003. We explored a bunch of options and ended up going with a gyro and integrating to get rotational position. This worked perfectly for the 15 seconds of autonomous, but unfortunately it would not be stable enough for Kelly's needs (where it would need to maintain correct orientation for basically the whole match).

As for reading the PWM input, sometimes you can take the PWM output and run it through a simple RC circuit to convert it to an analog value that you could read directly with the RC.

[Qbranch]

Originally Posted by Dave Flowerday

As for reading the PWM input, sometimes you can take the PWM output and run it through a simple RC circuit to convert it to an analog value that you could read directly with the RC.

Give me a pwm signal, a timer (internal peripheral) and an external interrupt (portb) and i'll time you a pulse...

Have had to do this this year and in the past for getting distance data out of an ultrasonic sensor...

-q

[Kelly]

How hard is that?

[Qbranch]

Algorithm wise its easy peasy. Hardware wise, you'll need to know how to use interrupts, and how to use a hardware timer... nothing too bad.

If you'd like to try, i'll write up how you do it, just don't want to take the time to write it till i'm sure somebody needs it. (call me lazy )

-q

[Dave Flowerday]

Originally Posted by Qbranch

Give me a pwm signal, a timer (internal peripheral) and an external interrupt (portb) and i'll time you a pulse...

Yes, that's not hard to do at all. I was simply offering a potential alternative solution in case the original poster isn't comfortable using timer interrupts and such. Occasionally things which seem most obvious to one person can be very daunting to another.