How much would you pay for a robot?

Everyone who started building or conceiving a robot think to set up a production and sell them to make big money. I had same thoughts, but not longer than a flash of light :-)

The robot must be smarter than commercial, but much cheaper. It has to carry much more payload, but be cheaper again. ...

I think that best way to succeed in this hobby is to make it a business. One need to open a company or bring together several professionals who agree to spend their time after work. This will take years to become something on the market. At least one need some time to make a team and define directions. I guess this would take one year until a prototype is ready, not even talking about software. I do not think that robotics companies going to wait until the prototype becomes a product. Please do not take it personally, just ...

I would find people around who have same ideas and start doing something. Unfortunately I could not find anybody in MA (might searched not too long). Sorry that I did not do robots and take advantage living in CA a few years ago. The only place where one can find people who share your ideas in every second home.

Good luck, Ek

Reply to
Ek
Loading thread data ...

I have all of my software running in C on the PC. It is unimpressive to me. Yes, an interpreter is faster on a PC than assembly on 1mhz 6502.

A robotics friend is converting my C into windows c++ with nice GUI.

Rich

Reply to
aiiadict

Does anyone know where I could get a remote robot with stereo vision? Just one that you could run from a PC? Is this pretty advanced at the moment? I wouldn't think it would be too hard to create. Has anone done so? I checked out those cye robots but they're over 2 grand and only have one camera. They're demo is pretty sweet though.

Reply to
godavemon

A real robotics platform? I must be missing the "real" part of it.

Computing power does not a robot make. Usable payload without a purpose, is not useful. On-board networking at the PC level has little to do with robotics. Wireless networking has nothing to do with robotics. Remote control means what you are describing is not be a robot at all, but a glorified RC toy.

A laptop (or motherboard) with wheels is still just a laptop. It has the disadvantage of being able to move out of reach. A wireless network will make it a laptop out of reach, that you can radio reach, remotely. That doesn't make it a real robot either.

Putting in computing power to run an Operating System does not a robot make. An Operating System is a HMI, a Human-Machine Interface. A robot doesn't need a HMI, unless it needs a human to run it, which again makes it an RC toy. A laptop with an OS and a remote control is still an RC toy with a very very expensive wireless link.

As someone else said, the best robots don't have operating systems at all. What Operating System does your washing machine run? None. Yet, it is a very popular electromechanical system with very little computing power, yet does a very useful funtion. What Operating System does your dish washer run? None. Yet, it is a very popular electromechanical system with very little computing power, yet does a very useful funtion. What Operating System does your toaster run? None. Yet, it is a very popular electromechanical system with virtually no computing power, yet does a very useful funtion. What Operating System does your toilet run? None. Yet, it is a very popular hydromechanical system with no computing power, yet does a very useful funtion.

Then, all the things it takes to make a basic robot (as opposed to a laptop with wheels) are missing in your description. Analog outputs for the wheels don't make a control loop. You need quadrature feedback to accomplish real wheel control to do Odometry, to do Navigation, let along steering to drive in a straight line. You need current sense to know if your wheels are stalled. You need various rangers (sonar or IR) to be able to do avoidance. You need bump switches at an absolute minimum. Those are the sort of things that make a "real robotics platform".

Roomba has most of those features. Seems what you describe is less of a robot than the Roomba. By comparison Roomba is an almost brainless robot, sans OS, ...but!... Roomba is a robot with a purpose. Any robot with a purpose will outsell any robot without a purpose.

I don't want to sound too critical, but I am amazed of late at what people think a robot needs. To try to explain my reaction, I'd have the same response if someone told me they were building a new automobile, and they showed it to me, and sure enough, it had four wheels and a motor, but no steering wheel, no seats, no brakes, no bumper, but had a really fast laptop, instead, running Linux. Want to go for a ride? Sorry, that's not a car. I have the same reaction to this laptop with wheels. So far, that's not a robot.

Reply to
Randy M. Dumse

I'll second this. A robot is absolutely NOT a PC on wheels. It's amazing how the first thing folks think of when building a robot is what kind of motherboard they'll need and what kind of OS, networking, etc.

The fact is that these are probably tertiary considerations at best for most real robots -- and OS should be even farther down the list. Mobilty, sensing, and general mechanical and electrical robustness should be first-order concerns. The Roomba, by the way, excels in the robustness area.

As far as computing power goes, lots of I/O is far more important than the ability to crunch numbers for most robotics applications. The latter need not even be done on board the robot itself. Any sizeable platform should have a massive amount of analog and digital I/O. Microcontrollers tend to have this in spades. Personally, I use one or mutiple networked microcontrollers (which are using no OS at all), possibly speaking to a local, more traditional SBC if I need or want computing power on board the robot. The SBC may be absent entirely, however, and any required computing done remotely.

I think the "PC-First" mentality tends to pop up a lot with software guys (and there's no disrespect intended here, as I'm one of them) who get into building robots for the first time. This is, however, definitely putting the cart before the horse, at least in most cases.

Reply to
the Artist Formerly Known as K

Buy "real" I mean something that is the base for robotics development. Somthing designed for just that application.

All of these features which you dismiss are important at a base level for serious work. They may not be the purpose of your project, be it robot vision, motion control, what-ever, but most of the time these basic features either need to be there or make your project much easier.

That is true, but it is also true that a laptop (or motherboard) "with wheels" can be the basis of a robot, and that is sort of the point.

Here's where I'm not sure you are understanding something about computers. EVERY computer has an OS at some level, some more comprehensive than others. Even systems that boot off ROM have code that is focused on managing resources and hardare without actually being directly coded for the purpose of the application.

Using an operating system with common tools and utilities with some sort of desktop or workstation allows for an easier development cycle. One can compile, test, and modify code on their workstation and simply send it off to the robot.

Obviously, you can make a basic robot using a PIC or STAMP, but having a lot fully integrated environment does make it easier.

Like?

A purely mechanical washing machine does not, because there is no computer. The ones with computers probably run an embedded OS in ROM.

If it has a computer it has an OS, perhaps rudimentory, but it has one.

See washing machine. Actually, my new dishwasher does have a computer in it.

My "toaster" has a small computer in it, and it probably does have a small OS.

More to the point, my Microwave has a computer, my bread machine has a computer, my stove, my car (has many), as does my VCR, DVD player, Television, my telephone, the keyboard on which I am typing this message, my cell phone, the list is endless.

Each and every device with a computer has some amount of code dedicated to controlling the hardware and managing resource, otherwise known as an OS.

The quatrature encode must have been left off the list as an explicit item, but the line "2 wheel oppsed drive with 3rd castor with PWM/PID motor control" should have made it obvious.

As for using wheel motion for navigation, it is only good for rough dead-recking.

If you have encoders, you know when the wheels are stalled.

There are two cameras which can be used as IR sensors. There will also be bumper sensors.

A roomba is a novalty item. It may have a purpose, but it doesn't accomplish it very well.

I have a bit of experience in robotics. One of my jobs a long time ago was "Denning Mobile Robotics." We were building a mobile robot security guard. Many of the technologies we were developing then, are still being developed today. Robot vision, motor control, etc. We worked with people like James Crawly and Hans Morivic (sp?)

The #1 problem we had in developing our robot was the base level functionality. We needed CPU power for analyzing data. We needed reliable motion. Basically, the platform I proposed.

Reply to
mlw

The more computing power a robots has the more advanced it *can* be. You need lots of computing power just to get something with insect-like vision.

[...]

That was me and I was thinking of those little light seeking/avoiding robots.

[...]

And IMHO an *advanced* robotic development systems needs *lots* of computing power and and an easy environment in which to test the software.

[...]

I am sure mlw intends to have those extra things you write about as part of his system.

The reason I use a laptop is because it give you the best value in terms of computing power, which will be required in advanced robotics, and the PC has an abundance of developmental tools.

- John Casey

Reply to
JGCASEY

Be aware that you have chosen the most difficult kind of robot to build

-- a robot that is meant to be something for everyone. Do you expect your users to be able to add their own electronics? How is this done physically? In other words, how will the innards of your robot be accessed? What kind of internal networking (if any) would be used? CAN? I2C? RS-485? Something else? Do you have a bus design in mind? This alone would be more important to me than the amount of computing power available on board were I intending to add hardware.

Not neccessarily -- that depends on the project. Moreover, computing tends to be a commodity item. If I needed onboard computing, I'd far rather have a robot that allows me to drop in or remove whatever I need. Should I need long run-times, I'd rather be able to use the lowest-powered SBC that suits my needs. If I need more horsepower, THEN I can move up. For me, any robot tied to a particular piece of PC hardware is a non-starter.

But I think you'll find that it makes a poor basis. In particular, a general-purpose robot needs LOTS of sensing, particularly as it gets larger, if for nothing else than obstacle avoidance -- which is not really as trivial as you might think in unconstrained indoor environments.

This is simply not true. The low-end, IO-rich micro controllers I mentioned earlier do NOT use an OS (or even a bootstrap loader). Some of the smaller versions may have 256 bytes of program ROM -- where do you think they'd fit an OS? Even the higher controllers I typically use for managing I/O do not use an OS. When the controller boots, user program execution starts immediately. There are also micro controllers that _do_ actually support something at least operating system-like.

I would _strongly_ recommend you pick up a good book on embedded development.

But this isn't what we're talking about.

[snip]

As I mentioned earlier, this is not likely, particularly in the case of your toaster

[snip]

Nope -- see above.

Dead reckoning combined with sensor feedback is actually a critical component of most navigation schemes.

Nope -- wheels *can* and *do* continue to spin in MANY stall situations. Relying on encoders is the least reliable way to deal with a stall. Even current sensing isn't perfect -- personally I'm also playing with accelerometers to see if I can add some robustness to a current-sensing scheme.

What will you do about obstacles out of the camera FOV? If I'm already doing vision processing, do I also have to track IR blobs as well? What is the bumper coverage like?

As a floor sweeper (as someone else mentioned, it ain't a vacuum), it seems to do a reasonable job. It is also extremely robust.

Have you looked at the Evolution robotics platform? Whitebox robotics? Both of these basically take the PC-On-Wheels approach (although I don't know if WhiteBox is shipping anything yet.)

Reply to
the Artist Formerly Known as K

I think this position is a bit naive. A computer is nothing but a tool. A robot, particularly a mobile robot, is an application. Saying a computer on wheels is not a robot, is like saying a motor on wheels is not a truck.

While these statements are true in a very strict sense, you are not being intellectually honest because while a motor on wheels is not a car, a motor on wheels is the base of a type of car.

The robot described is a usable platform.

The "roomba" is nothing more than a toy with a rug brush.

I'm not sure how this paragraph affects this discussion.

I am not actually doing this for the first time. I built my first robot in the late 1970s with a Mattel BigTrack and a COSMAC 1802 ELF computer. The system could roam around the room and make the outline of the wall and display it on a TV screen. (The ELF had a built in video controller that used RAM for the display buffer, I simply used the display buffer format for an internal map.)

I subsequently worked at "Denning Mobile Robotics" and have been watching the industry since. You may not agree with my conclusions, and that is fine, but they are not simply the result of being a first time software guy.

The ideas behind this platform have been seriously considered: (1) Cost is a big factor, unless you have a company or a government grant, you are paying for this on your own. (2) Software development compatibility, I didn't think any special skills or tools (device programmers, special languages or environments) should be required. (3) COTS Like it or not, COTS (consumer off the shelf) has been proved economical and practical at reducing cost an increasing value.

In short, the platform described at the top post is sufficient to start your robotics project. It has all the things you'll scratch your head thinking about how to build before you can actually start playing with navigation, motor control, vision, and spacial dead-reconing. Everyone struggles with the initial design of their system. Which motors, how to build the platform, motor encoders, power supplies, etc.

On top of all that, there are no other things to buy. Everything else is included, OS, compilers, debugging tools, and virtually any other software you would need as well as device support for peripherals.

If you find your vision algorithm needs more processing power, just add a computer and if you wrote your system with the supplied MPI utilities, it will automatically use the extra computing power. How cool is that?

Reply to
mlw
[snip]

No -- I'm deliberatly overstating to make a point. Of course a PC on wheels can be legitimately termed a "robot" (so could an RC toy). My point is that for me -- and you DID request feedback -- the operating system and OS is the absolutely least important bit that (and I may not have made this clear) that would be WORTH PAYING FOR. I'd also contend that it's the least important part of a working design. OK -- more important than paint job.

Yes -- but you've requested feedback on how useful.

Re-read it -- I'm more concerned about I/O on a general platform than the particular high-level computing hardware used. The latter is commodity item, the former might actually be worth paying for.

Really I shouldn't assume anything about your background -- my apologies. However, based on some of your comments ("all computers have an OS of SOME kind) you DO seem to have been out of the game for a while

-- in particular as regards the use of micros (which isn't all that new).

On another note, I remember the original PE article on the COSMAC ELF

-- I believe the original dispaly was actually a 2 digit segmented hex display (with a single hex keypad for input), no? The video controller muist have come much later. That's right -- I'm a geezer too.

Obviously.

Compatability with what? Currently there is no standard platform, although Player/Stage is relatively popular (which is one decent reason to support Linux and some form of wireless networking). Do you plan on developing your own tools?

I wouldn't dispute this, but it doesn't change the fact that your system needs to have more than a fast CPU and wireless networking as it's central selling point. I'll try to point some stuff out that MIGHT make for a more interesting product at the end of this post.

It sounds vision-centric (not in and of itself a bad thing), but lacking in other areas. Not only do you have competition in this arena, it doesn't seem like a very compelling platform (at least to me).

Here are a few features that I think would make your platform a little more useful:

Obviously, start with a decent base and drive train. Bear in mind that noise can become an issue here.

Add in standard some reasonable motion control. The controller should be able to both read the quadrature encoders AND do current sensing. Some people would like programmable acceleration profiles for the motors (not a big deal for me). My controllers generally support the ability to compute x, y and theta on the fly, with the ability for an external process to update those as necessary based on sensor data. I have found this to be quite useful. The ability of the controller to maintain at least a straight line via some kind of proportional control (without external intervention) is a must. This can easily be done with a $9.00 microcontroller (far less in OTP versions and OEM quantities).

Come up with an internal bus that is easy to interface to. The motor controller would use this to talk to whatever controller is used at the top end, but it should be easy for a third party to interface to. I use a bus that supports just I2C for communications between modules and power, but there are other choices. There should be easy physical access to the bus and mount points for additional hardware.

If you do this, not only can you offer easy upgrades (servo controllers, additional sensors), but the system becomes MUCH more open for experimenters. You seem to have a "software first" bias in your current design, which IMHO is a mistake.

Use a material for the robot that is relatively easy to work, should someone wish to, say, mount additional sensors or other hardware.

A real plus would be good obstacle detection. By this I don't just mean a lower skirt bumper. Ideally the robot should be able to detect a collision along the length of it's skin. This can be as simple as having the panels that comprise the outside of the robot coupled to bump detection switches, and mounted so that when depressed, they issue a signal. Personally, I would only need to distinguish between left-front, right-front, left rear and right rear contact. If these panels are also easy to remove to get at the inside of the robot, and easy to drill, I think you'd have a real winner.

Provide an interface for a top-level controller (which could be anything from a linux SBC to another microcontroller) to talk to the devices on your internal bus. Sell the platform with or without and SBC and software, or provide the software for free and let your customer choose the SBC. The SBC may be intolerably obsolete within a year or two from purchase anyway, making easy, customer upgradability important.

Offer the same kind of product in a weather resistant model. I don't mean something that can be left out in a rainstorm, but a robust platform that can deal with humidity and a wide range of operating temperatures. Now THAT would really pique my interest.

Hope that helps -- tAfkaks.

Reply to
the Artist Formerly Known as K

: Putting in computing power to run an Operating System does not a robot : make. An Operating System is a HMI, a Human-Machine Interface. A robot

This is the only statement you make that I disagree with. I don't think an OS is for human/machine interfaceing. Without going to look it up in my Theory of Operating Systems textbook, the purpose of an OS as I recall it is to manage the access of processes to system resources -- CPU time, I/O, and storage.

While I suppose it is certainly possible to write a single program that handles multiple tasks, I've found even using a real-time operating system (ie - AvrX) for relatively simple tasks on a 16k microcontroller simplifies developement.

Reply to
Christopher X. Candreva

No, I agree with your original point. A PC on wheels is not a robot, but it can be the foundation for one.

Actually I diagree with you. The OS can make a huge difference. A lot of the tools one needs to accomplish various functionality are present in a good OS.

A good OS provides all the background management that supports your project without actually being important to it. Think about a word processor. To a writer, the OS means nothing, they only care about the word processor (if at all). The OS, however, is VERY important as it provides many of the ancilary things that make the word processor function, like file managemnet, memory, printing, display, etc. etc.

No, not actually, how much you would pay. Granted that there is some conceptual overlap, but not technically the same thing.

Just a note, even embedded controllers have software that provide features like communication, this is -- maybe primitive -- but still an OS or OS like.

No, an "OS" need to be huge, virtually all systems have an OS of some degree.

It was in BYTE and it was a three part article. The third installment showed how to use the 1861 video controller chip.

I would use Linux and construct a basic frameword built on MPI and a few other technologies. If you write modular functions, they would just run on any processor that had the CPU time.

Another couple reasons for Linux is stability and flexability. Cost also works as well.

k

Vision is the the thing that popped in my mind when I was writing. Geez, ultrasonic mapping, path planning, dead reckoning, motor control, the list is endless.

Yes, energy efficient and fairly quiet.

Current sensing is something that isn't nessisary. You can calculate power use by RPM of the wheels and PWM ratio output.

You actually need thus.

[Snip motion control]

It will have motion control as indicated in the OP.

It will have 24 digital I/O bits, 2 analog outputs, and 2 analog outputs. (actually 4 but two are used for the motor control) These operate off I2C, and the parallel port will be mostly available as well as USB and serial.

Actually, I was looking at some LEGO Mindstorms sensors and motors, and thinking of designing a interface for them.

I don't think I have a "software first" bias at all, but it is a fact that simple and cheap hardware can do more and be more flexable controlled by a computer than expensive hardware that is not. That is a reality, nothing else.

Aluminum and plexy. Few "curves" mostly flat edges.

That is interesting.

No, I think the computer and OS is integral. Computer 0 in the cluster would be the base and control the motors and the the main I/O system. IMHO Single board computers are a pain to work with.

A weather hardened robot is an interesting idea. It adds some challenges.

Reply to
mlw

`still no imagination, but,

Modular units would be benificial to most of us; like those shape-changing `bots where each unit is a robot in itself, but requires another module plugged into it for another basic operation. This way, people (without technical knowledge) can experiment with them to perform basic household duties; R&D governed by their own income.

Modules can be made to hold a Vacuum cleaner handle, while another one on the end of a pole (connected to the holding module) can be used to move it around...

How much should a module cost?

----------------------------------------------------------------------- Ashley Clarke

-------------------------------------------------------

Reply to
Mr Clarke

Heres where I'm not sure YOU'RE understanding something about computers. They're jsut a bunhc of transistors. Perhaps a few resistors, capacitors, and diodes as well, but the basis for them is transistors. Transistors are jsut switches. A modern computer is made up of billions of switches. You dont need an operating system to tell a switch to turn on or off. Besides, an operating system provide low level access to a bios. The bios tells the processor how to shift the bits around inside it to make it do what you expect of it. You could actually just hook a bunch of switches up to a P4 and shift the bits around inside it. IT would take days for each operation, but it could be done.

Prior to modern computers, they ahd gears and levers and such. No operating system besides the one between the operators ears. Those surely were still computers though.

Prior to that, most "computers" were women in the employ of the military working out firing tables for artillery. This is where the term computer came from. A person who computes. And that's all a modern computer does. It adds numbers. That's it. Subtraction, division, and multiplication all stems from binary addition and bit shifting.

I could make a calculator out of transistors. That's it. I could make it display the desired outcome of the operation it was asked to perform on the values I gave it. There is no software inside those transistors telling them to turn on and off. The software is between my ears. Just like the operators of the mechanical computers years ago.

I dont mean any of this to be offensive. I'm merely pointing out the fact that an operating system does not make electronics do what you want them to. The operating system is there to ease the ability for you to tell the electronics what to do. All of these features you talk about could be made using discrete components requiring no operating system at all. Does that make the functionality any less effective? However, that would require a large amount of space. In order to make this a more reasonable and usable size, these electronics are miniaturized. In order to access the billions of transistors in these small devices in a reasonable amount of time, a way of interfacing is devised that allows the speed of processing to be harnessed. This is what an operating system does. IT doesn't run anything other than an itnerface that allows you to access the hardware underneath.

Reply to
Andy P

No. With all due respect, you'll likely want to do some reading prior to design.

It was PE as it turns out (you're right about the grahics chip, though). A walk down memory lane:

formatting link

If you're going Linux, you should look at some of the work which has already been done in this area. Check the Player/Stage project at least.

Current sensing is used for stall detection. Checking the encoders alone is inadequate for a real-world design -- in a number of situations the wheels may not even slow that much. It is possible to look at encoder counts, check it against the current PWM duty cycle along with actual power output from the battery and make a guess about stall conditions, but this is unreliable, and needlessly complicated. There's a reason motor controllers frequently include current sensing onboard.

Again, you should look at what has already been done done this area. Honestly, even combining current sensing and encoder input is not 100% reliable.

I would consider this "I/0 poor -- particularly in the analog department". You should at least open up the I2C bus.

Be aware that plexy has a tendency to crack when drilled (unless a special drill bit is used) and cut. If you intend to use a material that can be easily worked with by your end user, I'd go with a different plastic -- I like ABS and Sintra -- but they aren't clear. Plexy can apparently introduce static problems as well. On the other hand, plexy domes look really cool.

I will say that I like a cylindrical form factor in a robot -- you can almost always rotate around your own axis to get out of tight spots without getting hung up.

A lot of challenges -- but there are no players in this commercial space (that I know of) that aren't extremely expensive. Your current design already has competition (although I suppose this all depends on your final pricing).

Reply to
the Artist Formerly Known as K

For a "computer" to be a "computer" it needs to behave in a certain way. Look up "Turing Machine." No matter how low level your system is, at start up SOMETHING has to set up the stack and so on.

No, but there does need to be an instructon.

In many ways, a BIOS is a rudimentary OS.

We are talking about the 21st century aren't we? We are talking about what is.

[snip]

Again, not to be offensive, but look up Turing machine.

A calculator is not a "computer" as the term is used today.

Reply to
mlw

I have done several embedded products based on either the Z80 or the 6502. Every one of them had some sort of control code nessisary for operation. Now, I'll admit that you can probably run a program in an embedded device without anything except setting up the stack pointer and interrupt hardware, but the point is, in modern practices, one doesn't do that.

Today, in the 21st century, we sterilize medical instruments before we opperate (well, except for, maybe, the HMOs :-), we test automobiles for safety, we have waiters and waitresses going into the kitchen through one door and out through another, etc. There are common acceptable practices.

Whether you write it yourself, or you get it from someone else, it is a common practice to separate the application code from the system code.

The system code or infrastructure can be minimal or comprehensive but, it is the "OS."

I'll be damned! All this time I was remembering BYTE, but I went into my file cabinet (I have the articles along with the data sheets and assembler code), and it says "Popular Electronics."

It is interesting, but I think it was you who accused me of being too software centric. That seems like it may be too much, although I am considering some of their interface methodologies.

Why do you think the encoders are on the wheels? The encoders are on the motors.

You are controlling the motors, not the wheels. The problem with putting encoders on the wheels is that there is always "play" in the gearing. So, while you can say, the wheel position will always be +- a few encoder points, there is no accumulated error.

The play in the gear box is *really* bad for PID.

Since the encoder is on the motor, encoder frequency and PWM when plotted against the motor's characteristics can tell you exactly how much current the motor is using.

As I think about it, you may not even need the encoder info to calculate current. A PWM motor amplifier is conceptually a current source. The output current should be directly proportional to the PWM applied as long as you don't saturate your inductors.

Detecting current in to the amplifier is a different matter, of course.

Yes, the I2C bus will be available on a set of screw connectors or plug. I'm looking for a good standard.

Plexi is a bit brittle, you are right. I hadn't given it too much thought. The idea for a skin was more aesthetic than anything else.

Circular robots are cool looking but very impractical. The effect you claim for circular can be had with hexagonal or octagonal, and you still get flat surfaces.

It is the competition that I find lacking. All of them have some cool things, sure, but none of them focus on computing environment. It has been my experience that computing power is one of the most limiting parts of robotics. Sure, enough I/O and sensors are vital, but actually processing that information *and* performing motor control, path planning, navigation, etc. make for slow robots.

On top of the computers is the operating environment. A version of Linux with tools created for modular robotic programming makes sense. Imagine a framework, which you can choose not to use of course, that has a well documented module specification. You declare the type of module it is and tell the system to use it. Depending on the type of module, motor control, vision, ultrasonic, etc. (yes it can be exapanded), it is run on the most available CPU. The "most available" CPU need not even be on the robot. The point is, you code neither knows nor cares where it is run.

Reply to
mlw

As I said -- you've missed a number of developments in the embedded world. Do some reading. Check into the PIC line of devices along with the ATMEL line. Myke Predko has a number of good books ("Handbook of Microcontrollers" comes to mind). I'm sure others around here can recommend other books. I think you'll find that you can cut both costs and development time for much of your hardware.

[snip]

I didn't say they were. My normal approach is to mount them directly to the armature shaft on the motor, or use motors with the encoders already so-mounted. Doesn't make a difference, though.

Yes -- I already mentioned this (you also need to take into account the amount of current currently available from the motor power source prior to modulation).

Or you could do it the easy way, and simply use current sensing -- but it's your design.

[snip]

Done both -- and no, it can't to the same extent, though both shapes beat square or rectangular.

Good luck with your project -- tAfkaks

Reply to
the Artist Formerly Known as K

Serious work? Serious work for a robot developer? or, serious work for a robot to do something?

PC's are all about developers doing something. But they aren't very useful for a robot to do something. I say PCs, laptops, motherboards alone are very poor bases for a robot because they have no interfaces appropriate to robotics built in. And that is my point.

Where are the quadrature inputs? Where are the PWM outputs? How fast a PID can you run with a PC, with the operating system in your way? Where are the timer inputs for the sonars? Where are the analog inputs for the IR rangers? Where are the digital inputs for the bumper switches (surely not the parallel port 'cause that's gone on most motherboards already, or soon will be)? PC's just don't have any interfaces necessary for the base robot. None of those applications are considered ordinary for the PC.

So how do you get anything done? Well, you either cripple the PC trying to make it do a task it is particularly unsuited for, or you use some other micro to do the interfacing task, and then try to figure out how to get it to talk to the PC.

Stamps or a PICs are actually more fit for robot interfaces, but they are very much early1990's solutions. As you wouldn't offer a 1991 20-MHz

386SX a good solution for a PC today, neither should you consider the state of the art 1991 micro for a good choice for a modern robot controller.

The modern microcontrollers are marvelous! (and unfortunaely, too often overlooked in the robotics community in my opinion). They are as far from PICs, as the 20 MHz 386SX is from the 2.8GHz PIII.

Some modern micros are even designed specifically for motion control. They have quadrature decoders built in. They have PWM output modules built in. They have mult-channel A/D's. They have timer modules with a multiplicity of operating modes. Their digital I/O have edge sensitive interrupts. They have serial channels of multiple kinds and networking interfaces built on chip.

They can read sonars with no additional hardware. They can read IR Rangers with no additional hardware. They can read bumper switches with no additional hardware. They can read line sensors with no additional hardware. The can also read GPS's or interface to cameras. And then they have fast CPU's with large memories which can do many, or all, these functions in multitasking splendor with processing power left over.

You know, I just wouldn't advise banking on that speculation. I've been around a while.

How much would I pay for a robot. I'd pay ~$200 for a Roomba. I actually did pay that for a Roomba, and my wife loves it. I'm glad I did. It does something useful and we're appreciative of what it does and how well it does it.

How much would I pay for a PC based box you are describing? I wouldn't. I own at least a dozen robots, the most expensive being ~$750 (without electronics). But. I've got nothing like what you describe.

You've been around some, too. With your experience first at Denning Mobile Robots, but then doing years of Windows programming since, are you up-to-date on modern controllers and SBC's? Relying purely on PC's, I have to wonder if you're still trying to build the robot you wanted to have in the mid 1980's. I do think you might be able to sell some PC based robots, 'cause others share your opinions. But to me, the PC lacks the interfaces to be successful, and carries a host of systems programs which will get in the way and hinder probable success.

I have a M5 Tank (cost me $50) I consider "a useful development platform", with a board stack I'm developing (target retail price

Reply to
Randy M. Dumse

PIC microcontrollers I hesitate to computers. Microprocessor, sure, but the term "computer" as it is used these days, but OK, I'll give you the benefit of the doubt.

I would still insist that there needs to be code to deal with the processor and the I/O. Now, in the 21st century, common practice is to separate that code from application code.

The battery voltage monitor (for low power shutdown should be sufficient. If you know the make up of the battery, lead-acid, NiCAD, or NiMH and its AH rating, the voltage is in direct relation to the available current.)

Current sensing is interesting as a topic, but the question is it's usefulness. If the data can be calculated in a couple microseconds (nanoseconds) from existing data, there is no need to spend milliseconds and an I/O channel collecting it.

Reply to
mlw

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.