Robot magazines/publishers looking for writers?

SERVO, Nuts and Volts, and Circuit Cellar will all look at articles from new writers.

And so do most of the book publishers, though you should submit a proposal for those.

-- D. Jay Newman

SERVO is always looking for well written construcion articles.

Just some advice: Submit schematics in a high resolution digital format. Something common like an AI file is good. Submit the BOM with manufactures part numbers, not vendor numbers. Take decent photographs. Use a high resolution digital camera. Remember that

300 pixels = 1 inch. Take photos outside in the shade on a neutral or white background. Use a bounce card to fill in the shadows. Save photos in a non lossy format if possible. don't presume you know how to correct them digitally.

Contact the editorial staff and ask what they need. PID and PWM have been pretty well covered.

just my $0.03

Didn't know SERVO had a Spanish-speaking version. (Though I think it would be "construcción articles," but the spelling is close).

To add to this, I would say article topics should be well-focused, talking about a specific aspect of robot construction (or construcción, for that matter). Some piece titled "How I Build My Robot Buddy" probably wouldn't be of much interest.

The market for robot books has slackened off in the last few years. It peaked in about '99-2000. However, a book on a unique topic that hasn't been discussed before could do reasonably well. Affordable vision, with software samples, is a good example, especially as it transcends the robot field.

-- Gordon

Actually, asside from experience 20 years ago, I have had little pure "robotics" experience. I've done a good amount in operating system programming, data acquisition, system design, software development, parallel computing, etc.

The interesting thing that I see, as an outsider that knows the field, is that the robots people are building, at least IMHO, don't work right.

You guys are talking about microcontrollers, and while sure, you can do it that way, but I've been writing software for over 20 years, and it just doesn't seem like its worth the work. It is all a lot of "little" stand-alone systems glued togeter.

I like a more integrated approach. Homogenous computing power. Central I/O management. Parallel computing is how to make it easier. Use a unified programming interface.

A modern computer is very powerful, the demands put on it by a wheeled robot are marginal.

I am writing with this perspective, trying to de-mystify robotics to the point where it is cheap and easy to build your own. Hell, you could do it with a laptop.

grr

be nice...

The thing you have to remember is that robotics, as a hobby, has limited appeal. Always has. Interest in it comes and goes. It tends to go up when some new, inexpensive piece of hardware provides an "enabling link" that furthers the art, or when a movie comes out that gets people dreaming.

The latter seldom produces anything worthwhile, but the former has provided little spikes that keep the momentum going. Like it or not, Parallax's Basic Stamp was responsible for one such spike. LEGO Mindstorms another. Cheap PC parts...um, hasn't happened yet. Maybe when the micro-ITX finally comes out.

Having written a couple of books, and offering low-cost mechanical kits for small robots, the one thing I've learned is that the majority of people into robotics are really interested in the tangential sciences. They want to play with a (fun) real-life application that lets them explore the thing (or things) they are most interested in. For some it might be AI; for others it might be vision. And for some, they are interested in learning about microcontrollers, because -- darn it all -- there are jobs in embedded systems design. There are far fewer jobs in robotics.

Building a robot can be fun, but most people have an ulterior motive for spending the time and energy. Have you considered their fields of interest, and opened your design to include these? This would make whatever it is you plan to write about interesting to more than small group of people.

My advice: get your Web site up and publicized. You'll be able to gauge interest in your work. Editors and publishers will find you.

There is a dividing line that determines if "little systems strung together" is a good thing or a bad thing. Take automobiles. Decentralized processing means that if a taillight assembly blows, the whole car does not go down.

By breaking up a problem into its simpler pieces, you can more easily understand its abberent behavior. You can also upgrade more easily this way.

Yes there is a point where too much is too much.This is typically evedinced by the expectations of the user. They will expect to motor PID with a basicstamp II, and failing being able to do that, they will upgrade to some sort of serially programmed motor control. When you offload every sub system to a module, you have to re-evaluate your expectations.

I used to cringe at this, but there is utility there. It allows people to play at a modular level, and insert a known good component, and write code around it. It is a hideous example for "proper programming" but a lot of personal roboticists, that is fine.

The Basic stamp approach is fine for learning, and that is what a lot of people want to do. When you put everything onto a single processor, into a single box, you isolate things from the end user to some degree, and you effectively say, "this is a sealed system" even if it isn't. You make debugging more difficult to the uninitiated.

Consider the spectrum of whom you wish to write for, and find a publication that caters to that group.

Mike

It seems a lot like C++. Hideous? Maybe.

Mitch

Absolutely true, but that isn't my point, and I'll explain at the end.

Not always true, but continue.

OK.

OK.

I have a number of problems with micro-controllers, and FYI -- I am not anti-micro-controller, i.e. having one run my keyboard, mouse, cell phone, TV, DVD player (sorta), etc. is good. To me, and you may disagree, a micro-controller, like you said, is a sealed unit. This means two things: (1) It does what it is supposed to do in a way that is predictable and reliable. (2) (IMHO the most important aspect) What it does is fully understandable and not subject to change.

The minute I find myself developing micro-controller code, the projects ceases to be a bigger project, and it is reduced to a micro-controller development project. It is distracting to change tool sets and development environments.

Now, just because there is a micro-controller solution to do something, does not automatically mean it is the best or desired way to do it. Take "WinPrinters" (Printers that use your desktop CPU to do a lot of their work.) Some of the early ones were little more than an I/O device controlled by the desktop. It didn't behave like a printer at all. Is this the "best" way to do something, maybe not, but these old printers, at least theoretically, could grow with the CPU to which they are connected.

Also, a lot of you seem to think that a micro-controller is somehow different than a PC. This is another thing that I think is weird. A PC is nothing more than a microprocessor. Maybe you guys don't want to get into the serious OS stuff, I don't know. For me, anyway, it is really easy to just write a device driver to do what I need to do.

I hear a lot about I/O, ok, sure, the little micros come with some neat I/O, but so what -- between $40 and $100 will get you most of the I/O you would ever need.

Lastly, operating systems. Oh sweet glorious operating systems. I have done my share of embedded development. Wire wrapped RCA 1802, Z80, and Hitachi Z80 based micro-controllers, no matter how "easy" you make it, it isn't "easy." The Z80 based embedded OS I wrote in the 80s was pretty slick, it supported many core CP/M calls. It was a multitasking OS with cooperative threads with priority (and a "real-time" thread that ran every NMI). It had two flavors, the one that got burned in EPROM, and the one that ran on the Z80 emulator on my PC. At one point I had an SPO256 chip for speech, and a serial ROM dictionary for text to speech on the CP/M console output. In short, I lived in this world for a good amount of time.

As I worked in the more generic software industry, I discovered what I knew, but never fully realized. Off-loading something to a micro-controller is a step you do when you have defined the functionality. It is easier to develop your functionality on a bigger system and then downsize appropriately for productization. If you are never going to "reduce" the functionality, why bother with a micro-controller? IMHO is isn't any easier and it is arguable that it is any cheaper.

A modern PC has all the computing power you would ever need, and if it doesn't, there are technologies like MOSIX, MPI, and so on that allow you to add power incrementally. If you need "real-time" and few applications really *need* it, you can use a RTOS system.

This is why your embedded systems are moving to Linux. Not because Linux is great, but because it is an embeddable OS and what it can do is great. Look at the Linksys wireless ethernet router, $29 on-sale with rebate, it runs Linux. You can even replace the Linux in it with a custom one that will run your programs. Do you mean to tell me that Linksys developed their wireless router code on a micro-controller? No, of course not, they developed and tested it on a Linux work station, then cross compiled it to the embeded system.

If you want to do micro-controller development, more power to you, but I don't think it is a pleasent experience anymore, and I don't see any real utility in it unless your application requires it.

mlw wrote: [...]

[...]

Certainly the "serious OS stuff" is an issue for me. I haven't been able to get a book that explains it or teaches it that works for me. Keep in mind this is a hobby and programming is not something I do for a living. I don't have that 20yrs of writing software that you do. Not having that hammer I look for some other tool.

My Amiga that came with a thick manual covering OS stuff I couldn't follow. But I had no difficulty with the thin hardware book and a bit of assembler. Once I found out how to turn the OS off I could run programs much faster which meant I didn't need the line routine to join the dots when drawing with the mouse. That was a 7MHz machine. With my 800MHz PC I notice the line routine is required in VC++ and the Windows mouse/graphics driver.

So for me it would be impossible to write a "device driver" for an OS. I don't know how many robot hobbyists are experts at things like writing device drivers or how many students would find it a breeze. If the majority who might find your robot interesting fall in this category then there is no problem.

So it comes back to how many people are entering at your level of explanation?

Apart from that I would be interested to see you complete your PC based robot as a proof of concept if nothing else.

John

I would recommend Andrew Tanenbaum's "Operating Systems Design and Implementation." It is a very entertaining book that covers a lot.

Turning off an OS?

That's just false fear. On Windows, the DDK is intimidating, poorly documented, and IMHO badly written.

On Linux or FreeBSD, it is fairly easy and there are plenty of explample drivers that you can modify.

That's an odd statement. Are you saying vision, echo-location/ranging, motor control, and other things are harder than a simple device driver? If you can program in assembly, you can write a device driver. Don't you think?

The point of a device driver is that other's don't need to write them.

So far, I have not needed to write *any* device level code for my robot thus far.

Right now, it is moving back and forth in my lab. I've posted the motor control code.

If you can't use it no point having it?

In fact Amiga game programmers turned the multi-tasking OS off while their programs ran as it did rather slow things down on a 7MHz machine.

Assembler is a very simple language. As my first hobby was electronics I understand how a generic computer works at the hardware level to the extent I could build one out of discrete IC components.

I don't really know what is involved in writing a device driver for a multi-tasking OS. I have however seen all the "paper work" required to do something as simple as grab an image from a web cam. Even with my background in electronics I could never have programmed in Assembler if all I had was a technical users guide on the cpu in question. I relied on people with a University background who could use these manuals to write books for people like me.

I can't explain to anyone how to write a device driver or grab images from a web cam but I have books that have explained how to process images. An image is simply an array of bytes, full stop. Getting it there from a web cam is the trick.

Here is one of my first efforts using the old QuickCams and the DOS based DJGPP compiler.

/*-----------------------------------------*/ /* The main program /*-----------------------------------------*/

main(){ unsigned char exposure = 180; setVGA(); printf("Setting Up GreyPalette and QCAM\n"); GreyPalette(); SetUpCam(exposure); // set up cam GetFrame(Buffer2); DisplayImage(Buffer2); getch(); SaltPepper(Buffer2); DisplayImage(Buffer2); printf("Now we shall Edge the image\n"); getch(); Edge(Buffer1,Buffer2); DisplayImage(Buffer1); getch(); setTXT(); }

Now is it that easy with Linux?

But they do need to know how to *use* them.

What kind of smarts do they need for this?

?!?

Just trying to help you determine your target audience/intended publication.

Mike

Decentralized

Stopped the multitasking, probably, but an OS is far more than just scheduling.

Yup.

On a UNIX it is fairly simple, and it probably only take you an hour or so to "get it."

Gack!! That is not *simple*. Device drivers are easier.

Yup, and the problem with camera interfaces is that they all suck. I think multimedia, especially on Windows, is a disaster.

One of the things about UNIX that makes life real easy is that *everything* is a file, and *everything* can be accessed with read(), write(), and ioctl().

That's what made the mouse wheel encoder easy, just open("/dev/psaux", O_RDWR); Villa! I can read my mouse.

Actually, if you just want to run the Logitec QuickCam, yes. If you want to be able to run with *any* video subsystem, then you need to use V4L (Video For Linux), which is a bit more complex because you have to deal with video image format. Some cameras are B/W some are color, there are different bit depths as well. Once you manage these little issues, virtually any camera supported by Linux will be supported by your application.

In UNIX, not really, write a command using write() or ioctl(), and read the data. *Everything in UNIX is a file.

Minimal.

Electronics experimentors and computer programmers.

That goes without saying. I think Mike was asking the technical level of the readership, and the intrinsic goals of the publication. There is a wide variety in both.

Example: Almost all of Circuit Cellar's articles are on embedded computing, and their author's guide makes this clear. Therefore, your design would likely not find a home in that magazine.

Mike and I both write for SERVO and Nuts & Volts, so maybe it's just ingrained in us to think in this way.

-- Gordon

Si,

I think your ideas have merit, but I am concerned that it is too high level for the average magazine reader.

Remember too, that there are different types of robots, and different types of robot builders. I like designing robots. I have been coding for 30 years, and loathe it. I am perfectly happy shoving a microcontroller in a robot, and to me, there is no mystery in this.

The opposite side of the tracks is the hardware illiterate code jockey that wants a room rover. He has no idea what an H-Bridge is, but can write DLLs, and may even understand IRQs.

I personally have not seen a whole lot of people in the middle ground(read professional robotics engineer)

I do believe the vehement resistance you have received regarding the inapplicability of microcontrollers is a general opinion held within the personal robotics community. It is my opinion that your average SERVO reader, and certainly your average Nuts N Volts reader, is more interested in microcontrollers than an embedded PC. THis is afterall, the age of the jellybean microcontroller.

That isn't to say that there isn't an article in there, I would just choose your course carfully.

I agree with Gordon about CC. It is an embedded journal. There was recently an excellent PID article in CC, just as a matter of note.

Your other option is a book, but there is, as Gordon pointed out, a decline in book sales, and robotics interest, in the last year or more.

If you wanted to get my attention in a magazine article, I think that showing a definitive path through Linux and GCC might be a way to go. Like I said in an earlier post, PWM and PID are pretty much done well, and well done.

How about path planning Genetic programming Sensor fusion Stereo image recognition

Mike

I love circuit cellar, I get the magazine when I see it, and usually buy the book of articles when it comes out. It is good reading. Alas, I know my robot is not a circuit cellar article.

That's cool. The last time I published was 10 years ago (or more). I have written so many white papers and API documentation, that I know my skills have improved. (If not my typing)

Any assisence you are willing to give will be appreciated.

Like I said, publishers/editors will find you. The book and magazine editors scan groups like this, and they come upon Web sites, just like the rest of us. When I was helping put together a series of books for McGraw-Hill, two constributors of this group caught my attention (Dennis Clark and Michael Owings), and I followed up by looking at their Web sites. They agreed to do the book, and it turned out very good, IMO.

Personally, I am taking a sabbatical from the commercial robot book biz. Another author will do the revision of Robot Builder's Bonanza, and I can move on to new opportunities. But I know a couple of publishers are still willing to give the occasional good idea a try. Your Web site will be your curriculum vitae, so plan it carefully.

Read Mike's response elsewhere. Note particularly his suggestions of vertical topics, like sensor fusion and stereo imagry. He is bang-on right with this approach.

-- Gordon