![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Le_Forgeron <jgr### [at] free fr> wrote:
> Le 08/06/2011 20:29, Aydan nous fit lire :
> >> > News flash: Robots can't do this either.
> > They absolutely can. Have a look at industrial robots
> >
>
> Well, in fact, industrial robots have sequences of fixed positions on
> end of run for each axis (be it a translation or rotation) to regularly
> reassign the reading of their sensors. Usually perform at start-up and
> during the production cycle.
>
> (kind of: push motor to maximum right (against physical stop), store
> sensor value. push motor to maximum left... store value. Update sensor's
> dataset (for interpolating curve of sensor))
> For advanced systems, the physical stop can be replaced by video capture
> with pattern matching.
>
> Even the coding wheels (alternative binary on strips with different
> frequencies) can only be assumed to have an accurate relative value.
>
> And if you know a bit about using a graduated wheel connected to a
> screw, you know that you must always measure by moving from the same
> direction, as the screw does not fit the bold exactly in both directions.
AKAIK industrial robots use stepper motors and not positional sensors or coding
wheels. The step size of the motor is known as is the play on the gearing. Which
by the way can be mechanically minimized by having a springloaded secondary gear
which presses the primary gear against the driving gear to minimize play.
So you know the positioning accuracy from that.
As long as the motor doesn't miss a step, which is ensured by using acceleration
curves and such so you limit the momentum of the motor, you can move without
recalibration for a long time.
CNC mills for example can take several hours to machine a piece and AFAIK they
don't recalibrate inbetwen.
Recalibration is usually only done when the robot/CNC machine starts working or
if an error occured, because it takes time and time is money. Recalibration is
also not done by moving against a mechanical stop. It's done by moving to a
reference position with a special sensor, usually a light barrier.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 6/6/2011 12:40 PM, Orchid XP v8 wrote:
>
> It's quite clear that the design motivation behind this was not chip
> space but OS support. Compared to the space taken up by huge caches, a
> piffling 7 registers is nothing...
>
Actually, this is exactly why the aliased the floating point registers
in MMX. Otherwise, without the OS supporting the new registers, all hell
would break loose when the OS handled an ISR, because it was not aware
of the new registers and didn't properly preserve their values.
(Remember, interrupts only store the flags and the instruction pointer
before being serviced. It's the job of the ISR to preserve any other
registers.)
But how could that be? If the OS isn't aware, then it wouldn't alter
them, so they'll be fine. Except the OS does things like dispatch to a
game's input handler when a keypress comes in, and causes the screen to
redraw, which uses SIMD instructions to repaint the screen. Corrupting
the very same registers another program was using to perform some sort
of signal analysis in the background. Oops.
--
~Mike
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |