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
http://enerd.ws/robots/

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). <ggg>

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.

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.

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.

[...]


[...]

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?

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

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.

 [...]

 [...]

Ok. I will just have to see if I can find an easy
way to get up to speed on C++ for Linux in the small
amount of free time I have available.

What editor/compiler do you suggest?

-
John Casey

I'm a purist. I use vi, but if you are familiar with Visual Studio, try
kdevelop.

Compiler, gcc and g++.

?!?

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

Mike



I/O,

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.