?

Log in

No account? Create an account

Previous Entry | Next Entry

We put the Men in Menses

Well, I finally got target hardware today with which to develop code.
Unfortunately, the hardware does not work.
We are handing off the first integrated code set on Thursday. So far,
nobody has actually tested the integration.

39 days remaining.


Rabbit Semiconductor has a new nifty embedded product. It's a core
microprocessor board with an expansion bus. The idea is that it acts as
an interface to the external world with ethernet and serial bus
connections, and a bunch of bus connectors to attach to your device that
you want to communicate with. There are existing software bundles,
including a real-time OS, web server, SSL, and a bunch of other nifty
stuff. And it actually has enough memory (both flash and SRAM) to be
useful as a fairly sophisticated system on its own. It doesn't have any
graphics capability directly, which is befitting its intent as a
controller. But the top end model has a 56MHz clock.
That's a lot of power for a microcontroller. It puts it in a category
somewhere above appliance controllers, but somewhere below a PDA or cell
phone.

It would make for a dandy internet-accessible security system or home
automation controller. And it fits in rather nicely with a design
concept that I have for a location motion control camera system.

What I'd really like for it would be a compact flash card reader and a
USB2 interface. The idea of offloading all of the user communication and
file system onto a separate dedicated processor makes for a happy Rob.
It makes the architecture of the deeper system much easier to handle:
the user interface typically takes between 50-80 percent of the
development of a product, and is critical for acceptance in the
marketplace.

I have a design philosophy that allows for multiple hardware processors
for control systems. When you create your architecture, if you can
isolate blocks of functionality, say for a servomotor controller, that
is the perfect place to put a single simple processor. Get that small
piece designed and debugged, and you never have to worry about it again.
Make it modular and general-purpose enough, and you can re-use your
design in multiple projects.

This rarely happens in the industry as a whole. The primary design
philosophy seems to be one single processor to do everything, and either
multiple threads or tasks or some forced synchronization method in
software; the idea being that "software is cheap", and once it's
developed, there is no further recurring charge-- you don't pay for
parts. And there is a certain logic to this.

But for something like the servo motor controller that I spoke of
earlier, the additional hardware cost is somewhat less than $2.00 to
control 8 servos. If you sell ten thousand units, that's a cost of
$20,000. Industry standard engineering costs are estimated at $100/hr,
which leaves 200 engineer-hours to develop the hardware and software to
do this same thing. That's two engineers at 2-1/2 weeks full time, and
it's more reasonable to assume that that development won't be full time;
loading usually runs between 50-70%.

For a business that projects sales in the 100,000 units or higher, it
makes a lot of sense. In my case, selling a thousand units of something
would be nigh unto miraculous, and if it ever got that far I would
probably be in a position to get into a much larger business model.

It also makes a lot of sense for me to work on the basis of small
control modules, because so many of my projects deal with interfaces.
Small RC servos, DC motors, stepper motors, AC triac-based controls,
relays, things like that. Sensors for temperature, humidity, pressure,
speed, flow, position, direction. Timers. People sensors. There are a
lot of little things, and they are useful from project to project.

For instance: an RC servo works by giving it a signal that is
proportional to the position that you want it to be in. The programmatic
interface for this is probably a single number with a range of say
0-100; 0 represents "full clockwise" and 100 represents "full
counterclckwise", 50 would be in the middle. Inside the servo, there is
a position sensor that determines where the servo head is along its
travel, and a DC motor controller that turns the motor one way or the
other depending on how the reference signal coming in compares to the
internal position.
Now I have a design that needs to do something similar, but it's much
bigger than what an RC servo can handle: a camera lift. What I want is
for the camera lift to operate in exactly the same manner as the RC
servo: a 0 represents the full down position, and 100 represents full
up. That way I don't have to change my software, and I can test and
develop on a camera lift simulator that uses RC servos.

All I really have to do is emulate the internal workings of an RC servo.
On one side, I have a large DC motor with a gearbox that drives the
lift; on the other side, I have a position sensor that indicates where
the lift is in its travel. I do the same comparison internally in my
hardware that the RC servo does internally in its hardware.

Of course, the real world isn't as easy as that. There are a lot of
other factors that come into play, like speed and response time,
inertia, little things like that. In real-world complex control systems,
a type of controller called a PID (for Proportional, Integral,
Derivative) controller is often used. It enables the designer to specify
how the system responds, and can make for much smoother motion overall.
There is also noise to consider: mechanical parts make noise, and in
general, you want to minimize noise during shooting.

The idea behind the use of a motion-control rig is repeatability: you
can program in a camera move, and it will be repeated as many times as
you need it to be. The MoCap data can also be exported into files so it
can be used with 3D programs or other systems for special effects, but
for this purpose I'll just stick with repeatable camera moves. That
alone makes for some wonderful effects possibilities.

On the upside, I can define the parameters like maximum speed, or time
for full travel. It means that I can use those design parameters to
limit the movements so I can get repeatable performance without
resorting to the expensive PID controllers.

I even have a name: Loco Moco, for Low-Cost Motion Control. (This
also translates to crazy booger in spanish. I find this amusing.)



Comments

magicmarmot
Mar. 22nd, 2005 11:40 pm (UTC)
It was distracting to write. And that was a very good thing today.

Latest Month

April 2012
S M T W T F S
1234567
891011121314
15161718192021
22232425262728
2930     

Tags

Page Summary

Powered by LiveJournal.com
Designed by Tiffany Chow