what is the most popular plc or processor for balance bots currently?

the one you are most familiar with.

No no no! It's the one *I'm* most familiar with!

In other words, Bep is correct. Unless the OP is specifically trying to learn a new processor (in which case a balance 'bot is a rather aggressive platform for learning) the particular processor (family) isn't all that important, although a working knowledge with the family and its toolchain is a definite plus.

Start with the basics: Many small, networked processors? A few satellite processors and a central brain? One big processor to run everything? What needs to be sensed? Sensed how and at what rate? What needs to be controlled? How controlled and at what rate?

Answer those questions first and then find processors that meet those needs (plus a little headroom).

Rich Webb wrote: > On Sat, 03 Apr 2004 14:08:28 GMT, "Blueeyedpop" > wrote: >

But, what Bep and Rich said is true, go for a familiar processor.

Good luck,

Peter

look at the sensors you intend to use, and make sure the processor will interface.

More processing power helps, because you can implement more complicated digital filters.

I suggest an analog output gyro that can be coupled through a cap to remove the DC component of the gyro as a possible start, since you will want to integrate to velocity.

Encoded motors are nice, because you can do delta position to get velocity.

I took a quick stab at it with decent results with a plugapod from newmicros. It has timers to read the encoders and analog devices accelerometer, and analog to read my silicon sensing systems crs04 gyro.

Mike

I have experience with the 68HC11, but I could have used more input timers, discretes and D/A. I added the port expansion chip for the 68HC11 to get 4 input timers, but it would have been nice to get more on one chip. The 2 MHz speed seemed plenty fast for most applications, but I'm just wondering whether anything better has appeared on the market. Any recommendations, anyone?

Mike Ross

Blueeyedp> look at the sensors you intend to use, and make sure the processor will > interface.

Well, in the 8 bit world I'm sold on the AVR processors. Nice architecture, GPL toolchain [1], inexpensive in-system programmers.

The ATmega series have quite a few capture/compare registers and several timers. No D/A as such but there are set-and-forget PWM channels.

Up through the 32K-flash ATmega32, the chips are available in DIP form factor. Handy for breadboarding.

If you want to give them a try, recommend the STK500 "starter kit." It breaks out all the I/O ports and also has an on-board RS-232 level shifter for talk-talk with a PC. Can be used as an in-system programmer to a device on a different board.

I'm really sold on the IsoPod, PlugaPod, and TiniPod from new micros.

Up to 12 PWM, 16 timers, quadrature decodeing, 2 serial ports, SPI, and CANBUS.

Second that.

Don't forget that all the ATmega and ATtiny series chips have on-board oscillator for "no-external-parts" operation. Just power and ground (er, don't forget those bypass caps - that sort've goes without saying). Making your own proto-boards doesn't get any easier!

Plus - it's a modern architecture with lots of nice features, both in terms of the CPU architecture (simple, orthogonal, powerful, and fast instruction set with lots of registers - makes for fast, compact, code) and also in terms of the available on-board hardware peripherals available.

Also seconded - while the STK500 is the "cadillac" board, it's sort've a swiss army knife because you can use it not only for development using the sockets on-board for all of Atmel's DIP parts, on-board LEDs and switches for experimenting and learning, but also with its ISP programming headers it can be used to program third-party boards that use the same header footprint (like mine - see sig).

I use the GNU toolset on FreeBSD Unix - a very fine programming environment. BASIC is also available for those who prefer that - BASCOM-AVR seems to be the prefered choice there.

Brian

-- Brian Dean

I like to work with the cygnal 8051 family,.. no, they changed name, it is silabs now. You can debug the running program with breakpoints, single step etc. and a lot of posible members in the 8051 family + with the prototype board you can run a robot.

As you see, everybody has it's own 'best' solution :-).

Good luck,

Peter