Believe it or not, I do have a copy of "Robot Builder's Bonanza." I also have "Build your own working robot" by David Heiserman, as well as over a dozen books on robotics, a number on power circuits, industrial control, and many others on hardware and software design and development. I am not a person without knowledge or background. One thing that I find disturbing about this whole conversation is that you guys take a contrary opinion personally. It is possible to have a contrary opinion and still (a) know what you are talking about and (b) have thought out the design.
The "Bonanza" book is good as a beginners text, a lot of subjects and nothing in great detail. I'm not saying it isn't an excellent book, I've been through the publishing mill a couple times and I hate it. You are certainly to be applauded for the amount of work you did. I hope it pays well.
In the late 70s and early 80s I built a robot. It was based on an RCA 1802 ELF and a Mattel big track. It was cool. It could do a lot of things. Developing for it was very hard. I had to hand code the ROM and toggle in the code.
When I got my first computer, a CP/M box, I got an eprom burner, and burned eproms. It was all painful, but I didn't know better.
In 1984, I started working at Denning Mobile Robotics. We designed robot that was primarily based on a 68000 and a number of Z80s. The Z80s were a pain, buring eproms, using in-circuit emulators to test, etc. The 68000 system was better. It had memory, a real OS, and worked seamlessly with the systems we were using for development. (At least it seemed seamless at the time).
It became clear to me then, and it is still perfectly clear today, that the robot should work like the rest of the systems around it. It should fit in seamlessly.
I don't want the microcontroller disconnect. I want to be able to use my standard tool chain to create software for the robot. I want it to work like the other computers in my lab. I want it to be able to use computing resources external to it. Those are part of my personal goal for the sub $500 robot, and I would think that you could respect this position.
This isn't a theoretical debate. You're missing a lot of useful input. Did you catch, for example, that Jay Newman builds robots using Linux and mini-ITX boards, is writing a book about it, and has a blog detailing his experiences? His sig contains a link to his page. The work is taking some time because he has a day job, but he's sharing his knowledge with the rest of us. Jay regularly helps people here working along the same track.
Yet when Jay, like most of us, strongly suggested you might need to offput some processes to a subcontroller, you once again challenged him with why. The why should be obvious by now, and it's been explained enough times by people with more experience, including those who have actually built what you're proposing, and with Linux. These people have been willing to give you their time, so you should respect their position as well.
I think you're ready to go to your shop and just do it. Write up a page, and share your techniques. Let's move on.
Everyone? That's simply not true. Perhaps people are taking things personally because you're not paying attention to what you're writing. With a little more care, and less sweeping generalizations, I think you'll find you won't piss off quite so many people.
One $5 PIC chip can have >30 i/o pins that can actually supply a usable current (25mA) and that won't burn out at the drop of a hat. At any rate, parallel ports are legacy devices coming to a rapid demise. Why do you wish to make your device of the future rely upon hardware that will soon cease to exist?
A bunch of micros now have USB interfaces in them. FTDI chips can take up the rest of the slack. I think it's safe to say that USB (and possibly firewire) are becoming the defacto standard interface to most external devices attached to a PC.
So what, you already have one present, why not use it? Many ITX boards have a connector right on the board to let you hook up to it. They may call it an SMBUS connector, but it's compatible with I2C.
I don't think assumptions are an option and frankly I'm surprised you would ask such a thing.
I really don't understand your motives. You come here asking for advice and then you go to great lengths to refute every bit of it, including building straw man arguments and then burning them down. Outside of being a troll, I don't know why you'd wish to do that. Many people, with far more experience than you (or I), have told you the same thing, "keep your ITX board for central control and functions that requires high CPU performance or floating point math, but offload as much as possible to "smart" circuits that can actually do a better job." AFAICT, nobody told you that you should use a micro in place of the ITX board nor did anyone tell you that your idea absolutely would not work.
Whether you believe it or not, microcontrollers running at 4MHz have abilities that a 1GHz ITX PC platform system cannot duplicate even with an RTOS. Interrupt latency is the first thing that comes to mind. Then there's i/o, PWM, ADC, CCP, comparators, timers, various serial comms etc capabilities. Microcontrollers are intended to be the magic glue to interface digital electronics (like your ITX board) to an analog world. How could you conclude that everyone got this part wrong?
BTW, could you post a link to the "$50 IO board" that you refer to? I'd like to examine its capabilities.
The concept that John found on my site goes beyond a single robotic entity that can scoot around after someone and "lend a hand". In fact, a mobile robot is actually an optional (but too fun and interesting to ignore!) part of the project.
The core of the idea is home (or office) automation, but rather than being aimed at people who may be gadget freaks (or just plain lazy), the automation I have in mind is intended to push someone who is not quite capable of independent living, back into a self-sufficient way of life.
Inputs could include:
Client position tracking (what room are they in? have they fallen over in the shower?) - could be achieved with standard security hardware (PIRs, door beams, pressure mats, LAN cameras)
Weather (get HVAC* running BEFORE it gets too cold/hot inside, get washing in if raining, don't bother watering garden, etc)
Sensors on any dangerous equipment (cookers, toasters, heaters [temperature as well as CO for gas-fired equipment])
Personal alarm - this could be the traditional radio pendant or even microphones in all rooms feeding into speech recognition software; voice control could also be associated with lighting, HVAC, etc.
Monitoring for problems in bath/shower/toilet
Soil humidity (for irrigation)
Pump monitoring (if not on mains water; also shower and circulating pumps)
Shut-off of dangerous equipment mentioned above
Electric door strikes
DSL connection to monitoring centre via Internet/VPN; dial-up modem as backup
Internet -> SMS messaging to notify family/friends of non-critical alerts
Essential Movies ;-)
2001 A Space Odyssey
I've got some of the environmental monitoring working and have other bits under construction. (See weather page on my personal site) Irrigation partly done, pumps about to be put under "intelligent" control. About to put together a light barrier that determines direction of travel - handy for client tracking.
My reason for joining this newsgroup is looking for inspiration/assistance in putting something mobile together, my first mobile project being a wheelbarrow/mobile platform that can assist in fetching firewood from the log pile and move the laundry basket around as one hangs out the washing.
Phase II would be an indoor model (drone or scutter, depending on ones choice of viewing); although I can see various assistance roles that could be performed for disabled/elderly, I have to confess that I just want something that will carry my beer fermenters to/from kitchen and laundry, saving my back and preventing sloshing!
No, I am reading it, but I think you guys have an antipathy toward using a PC type computer and using it to do all the work'. It is hard to take many of the arguments at fce value because they make great leaps of logic.
I didn't see that, I will look.
I usually ignore sigs.
"More experiece?" A little presumptuous? I like to never assume anything during an engineering discussion. Experience in doing what? OS driver design? Motor control? Embedded developent? High speed data acquisition and control? Or is it experience writing micro-controller software?
I have a good deal of motor control experience. I have a good deal of high speed data acquisition driver experience. AFAIK, my data acquisition framework for NT may still be in use by keithley instruments on some of their devices.
I have spent many times over my career timing interrupt latency and data throughput on various systems. Regardless of your view, I do know a thing or two about what I am talking about.
No one, once, as said WHY I need micro in addition to an ITX board. Where is the engineering "proof" that the latency will kill me? Where is the "proof" that it will take up too many CPU cycles? All I get is the "we know more than you," "you'll see," or "you're too ignorant" arguments.
My current control loop spends most of it's time sleeping. When running, it creates less than 5% CPU load. Why do I need a microcontroller to control the motors?
I do respect their position, I simply do not agree.
I'm in the process, but I have to run to "You do it" tomorrow to get a power transistor. A slipped scope probe and a short to ground. :-(
In fact, a robot in an assisted-care facility makes a lot of sense because the environment is already designed in a way that naturally dovetails with the needs of a typical robot. The floors tend not to have rises, threshholds, or other causes for trips, the floor is smooth tile or low-nap carpet, the aisle-ways are usually wide, with few projections, etc.
Not all the automation needs to be mobile, as you pointed out, but a robot could provide an extra layer of safety and patrol. Not too many people are working on robotics for senior assisted care (part of it is libaility, but that's a subjective risk anyway), but I think this could be a real growth area.
Kudos on your work so far, and best of luck! Please stick around and share how things progress.
The question isn't "what is the delay," but can you factor in the delay and mitigate any out of band effects.
The relationship between the motor and the encoder, is similar to the wheel on a ship. Depending on the response time of the motor system, the instantaneous motor responses are great for position updates, but are only useful for trend information for the motor control. You will typically not see instantaneous response from the motors unless you have a very precise mechanical system. In a mobile robot, it may take multiple encoder reading to see the effect of a power increase of decrease.
My system uses a D/A converter to create an analog -5-+5 signal. 0V means stop. +5 is full forward, -5 is full back. The motor amplifier creates a PWM/direction to drive an H-Bridge.
Very low CPU usage.
And that is what a good motor control system does.
This is a stupid discussion. My statement about not wanting to use microcontrollers because I think they are too limited and because I don't want to develop microcontroller code is constantly being asserted as meaning that I don't like microcontrollers. Your assumptions about what I said are not what I said.
Actually those are 16 IR high current MOSFETs ganged 4 in parallel for greater current carrying capacity. Each row of 4 is a leg of the h-bridge. There's also a pair of high-side MOSFET drivers on there and an ATmega32 microcontroller providing the "smarts."
It does RS232, RS485, I2C, R/C servo pulse, and simple potentiometer control. The potentiometer can alternately be connected to the shaft of the motor and used to make a giant "servo" where it gives position feedback.
It also does quadrature encoder input and PID control.
It's not all done yet - not quite fully functional, firmware wise, but getting there.
I've placed 4 mounting holes to mount an Athlon CPU heat sink fan over top of the MOSFETs :-)
I torture tested it on a 20 HP E-Tek motor and it survived. Some parts did get hot, though. But it still works :-)