Randy said
> Good heavens! This is a tutorial how to throw away 25%+ of your
> processing power to service only 4 servos! All that is happening
> in that 25%+ of your processing is sequentially, 4 line, one at
> a time, goes up, and come back down.

It's a tutorial on how easy it can be to write a 4-servo controller.

The point is that processor time costs next to nothing. Processor time is
only expensive when you run out of it and have to buy a bigger processor.
If 75% of a cheap processor is more than you need to run the rest of your
robot then it doesn't matter if you've thrown away the other 25%.

My programming time, on the other hand, is always expensive.

> Rather than keeping explicit state information,
> a <begin check-timer until>  structure captures the processor's
> Program Counter, restricting it to a very short range of
> possible values. While the Program Counter holds those values to
> the exclusion of all others, no other processing occurs.

So what? The processor isn't an employee. I'm not paying it piece-rate. I
don't care!

I looked at using timers and interrupts and found that, using the processor
I had, I could get just as accurate timing with a tight loop. And it took
less programming effort.

The accuracy I needed was determined by the granularity of the byte used to
set servo-position - not by the granularity of the timing loop. I had to
put NOPs into the timing loop to slow it down.

My programming time is more important than the processor's time. Or do you
think I should write everything in assembler so that the PIC is used more
efficiently?

> So we have these loops checking a thousand times
> (or more) in a row if 1.5mS has passed, and disallowing a
> thousand (or more) useful things being done.

The PIC doesn't have a thousand other useful things to do.

> Now things like 1) timing the echo time on a sonar 2) measuring
> pulse width on accelerometers/gyros 3) taking A/D conversions on
> accelerometers/gyros 4) reading GPS sentences 5) etc. can be run
> concurrently with servo updates.

Were I doing all those ther things, I'd have a PIC dedicated to controlling
the servos. (I understand you can even buy such things ;-).) And I'd
program it using whatever technique was simplest to program. What saves me
effort not what saves the PIC effort. Writing a tight timing loop takes
less time than writing this paragraph. Setting up timers and interrupts
takes a lot longer. My time matters, the PIC's doesn't.

In this particular example (my biped), what else did the PIC have to do? It
had to send the servos though a sequence of positions - which took around
1% of it's time. It checked comms with the PC (around 1% of it's time). And
it had to check the two obstacle detectors (around 60% of it's time). An
obstacle detector works like this: charge a cap, discharge it through a
phototransistor, time the discharge, turn on an LED, charge the cap,
discharge it through a phototransistor, time the discharge, turn off the
LED. I've looked at doing the timing via interrupts and via a tight loop.
The tight loop can have variable timing resolution - you need more
resolution for shorter times, the response is logarithmic. Also the
interrupt would interfere with the servo timing. The whole point of an
interrupt is that it can happen at any time. I can't use interrupts for the
servos because they would interfere with the accurate timing of the
phototransistors. I can't use interrupts for timing the phototransistors
because they would interfere with the servos. By doing it all in tight
loops, I can keep complete control of the timing of everything. Perhaps I
could start turning interrupts on and off depending on what's currently
happening but that's getting awfully complicated and has no advantage.

I certainly can't use FSMs to do everything because the housekeeping
overhead means none of the timings would be accurate enough.

> Why more people don't get the FSM concepts, is a somewhat
> interesting point. As you say, it's not all that hard to do. It
> saves bundles of processor time.

I "get it". I know exactly how to write and use FSMs.  Please stop implying
that the rest of us are stupid because we don't always use them. We don't
always use them because they're not always appropriate. I don't care about
processor time. If a project manager spends his entire life worrying about
processor time, you fire him. Programing time, design time and software
maintainance time are important. That's what "structured programming" is
about. And please don't say that FSMs are as easy to program or as
efficient in programming effort. They're not. That was proved in the 1970s.
That's why everyone sensible switched to structured programming. The 1970s
weren't an era when intellectual giants bestrode the world and nowadays all
that's available are dim-witted C++ programmers. "Structured programmers"
aren't less intelligent, they're more efficient. That's why their employer
pays them to do it that way.

Look, I've been programming for decades. I've used FSMs many times, I've
used interrupts  many times and I've used dedicated timing loops many
times. I've known how to do all that stuff since (at least some of) the
people on this forum were in diapers. I know how to write programs that use
the processor's time efficiently and I know how to write programs that use
my programming time efficiently.

But most importantly of all, I know when to use which technique. There is
no One Size Fits All.

Peter

From: "dan michaels" <oric_dan@...>
> > With a quadruped tripod gait at 75% duty cycle, successive
> > triangles only abut (in Dan's gait 6). So the CoG has to leave one
> > triangle and enter the next one just as the old triangle is
> > disappearing and the new triangle is forming. That's tricky to get
> > right every time.
>
> Take shorter steps.

No. No. No. And again No. That doesn't work.

It's the right answer for he hexapod tripod gait but a hexapod has two sets
of three legs with which to make the tripods.

A quadruped has to make successive tripods by sharing four feet amongst two
triangles. Look at the animation I sent you. There is no way that
shortening, lengthening or otherwise altering the foot positions can make
gait 6 _always_ statically stable.

> This is one of the saving graces of Gait 6, as the CoG is always
> moving forwards onto the next triangle.

In other words, the only way to make Gait 6 stable is to rely on dynamics?
It is not always statically stable? A wind-up-toy algorithm can be made to
work on perectly flat ground but relying on momentum doesn't work on even
slightly uneven ground.

> But you'll notice the problem is worse with the other 5 creep gait
> sequences. As I pointed out, for instance, in Gaits 2 and 3 you lose
> support completely in some positions.

As I've said, in gait 2/3 successive triangles always overlap so, by
swaying the body, the animal can always keep it's CoG within a triangle.


From: "Randy M. Dumse" <rmd@...>
> So you have a momentum forward or aft, usually
> forward. If you pick up a back foot, and your momentum declines
> and reverses (as measureed by an accelerometer in fore aft
> orientation) you know you need to catch yourself, and reverse
> the gait to hold yourself up. Withdrawing the forward motion of
> the forward leg to shorten the stance might also provide a
> counter momentem working against the backwards fall. If you see
> the momentum as normal and still going forward, you expect to
> land forward very soon.

That could work. I've written a 2D biped simulation that balances using
that algorithm.

But it's not very good and I don't really understand why. It needs big flat
feet. I'd like to make a 2D biped that can walk on tip-toe but I haven't
managed it yet.

> I think the real key to the lower leg number gaits is to watch
> this dynamic indication of progress, and to have a "catch me"
> strategy when things don't go normal. If you have forward
> momentum barely increasing, and front foot contact soon, your
> fine. If it isn't soon, then you try to do two things. Retract
> the forward leg (try to shorten the length of stride to find
> closer ground) And reverse the path of the back leg. Both of
> these can stop the progression of the CoG, and hopefully let the
> body catch itself. Then beyond another point, the front leg is
> thrown out long ahead, to hopefully catch itself if anything
> support can be found along the forward path.

As a biped, I find that if I'm falling forward, then either:

1. I put down my Flight foot a little earlier then normal and pick up my
Stance foot a little earlier than normal so I can rush it forward sooner
than I would otherwise do.

2. I lengthen the stride of the Flight foot so it goes down ahead of its
usual position so it's ready to catch the fall forward.

Those two are exact opposites. Which one do I do? I'm not sure.

As you say, a quadruped could do domething similar. Which suggests that the
"standard" gait always has a little extra in reserve. You shouldn't walk at
the limit of what's possible for your body.

"Reverse the path of the back leg" works with my simulated 2D biped but it
seems a bit extreme for a quadruped. You're making me think I've got to get
my 3D simulation working well enough so that I can easily try different
control algorithms. (If you want to try your own 2D biped algorithms,
Google for "Planisim" and run the Biped2 file.)


From: "dan michaels" <oric_dan@...>
> >Keep theCoG moving forward. Don't let the CoG aproach the fron
> > of the current triangle unless the Flight foot is approaching
> > touchdown. Maintain roughly the correct phase relationships between
> > feet.
>
> Yes. This is what you get with the Gait 6 step sequence, and which is
> similar to the diagonal-walk of Jake on my page, and also the trot.

Is it?

Can you prove that if you put in the constraints I suggested (or any other
similar set of constraints) then gait 6 would "emerge" _automatically_?
That would be a very interesting result. Personally, I suspect you
wouldn't. I think you'd have to add extra constraints on the preferred
phase relationships of gait 6. In other words, you only get gait 6 if you
specifically force it to happen.

From: "dan michaels" <oric_dan@...>
> As I see it, bipeds and quads solve the problem Peter is talking
> about by using forward-spring in the legs, and also forward-inertia
> of the CoG such that the frame is "falling-forward" onto the new foot
> or support tripod.

So gait 6 isn't statically stable?

Yes, of course, animals use dynamically stable gaits with lots of feedback.
What we're interested in is whether it's possible to build a robot
quadruped that can walk reliably with no feedback (or very little).

From: "Randy M. Dumse" <rmd@...>
> Yes, but what I'm thinking is the recovery from forward falling
> is what gives the transition from reflexive walking, and walking
> in rough terain. I think the detection of an aberation in the
> walking is what beings focus. The lack of forward foot contact
> (stepping in a hole), or the early detection of forward foot
> contact (tripping, scuffing), or loss of forward momentum (going
> over backwards) have set responses that are also automatic, and
> trigger to help recovery

Earlier, you were suggesting that recovery from forward falling could be
done by speeding up or slowing down the gait timer. Are you now suggesting
there's a separate reflex which is different from normal walking?

From: Alan KM6VV <KM6VV@...>
> That would get more complicated!  Should it be done with a table or a
> set of states?

I think neither. The algorithm has to be continuously variable. A "set of
states" has discrete steps between the states. A table to to deal with all
the inputs from accelerometers and force-sensors would have so many
dimensions it would be huge.

I think the algorithm has to be more like an analogue computer.

From: "Randy M. Dumse" <rmd@...>
> > I wonder if these particular acceleration patterns could be
> > detected from a pair of accelerometers?
>
> A single dual axis device should do, and give you acceleration
> in the horizontal plane, both forward back, and left right.
snip
> there are some situations in flying where you
> can feel the same thing in two entirely different situations.

A single dual axis device can only measure the acceleration at one point in
the robot. If you have two of them at different points then you can measure
both overall linear-acceleration and overall rotational-acceleration. I
think that might help distinguish feeling the same thing in two entirely
different situations.



It is so _very_ hard to know how to walk. I think we're all just waving our
hands around in a hopeful but helpless fashion. Some results from even a
half-decent simulation would help a lot.

Peter

Could you convert it over to paypal?

--- In SeattleRobotics@yahoogroups.com, Leland Fox <leland_fox@...>
wrote:
>
> E-mail back to the seller through the ebay channels and ask them
to verify the request and explain the situation.  If it is a real
request, they will explain.  If it is a scam, they will tell you
that as well.  Perhaps they will negotiate with you regarding your
concerns for identity theft.
>
>   Leland
>
> eshezo ayomi <robo_seeker@...> wrote:
>           dear all
> i bought a set of 5 servo motors by net from the site :
> www.ebay.com
> as i was adviced...........
> but when i paid for them by a master card i was received a mail
asked me to send a copy from my passport or any government - iussued
photograph identification (ie : driver`s license ...) by mail or by
post ...............
>
> is this something normal..............
> i mean that this is the first time i am asked for
this ...........................
> please i need someone who use this site before to tell me if this
is normal ask....
>
> thanx b4
>
> Huthaifa Nabil Saifuldin
> Yarmouk University/Hijjawai Faculty
> Electronic Engineering
>
>
> ---------------------------------
> Never miss a thing. Make Yahoo your homepage.
>
> [Non-text portions of this message have been removed]
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>

--- In SeattleRobotics@yahoogroups.com, Alan KM6VV <KM6VV@...> wrote:
>

>
  If you really get a fast processor, or, hardware support
> >which does the pulses for you (like on IsoPod(TM)), you can
> >profile the acceleration, and the top velocity, so you get
> >beautiful s-curve profiling, where the servo starts slow, ramps
> >up, holds speed, then ramps down to a final position stop.
> >
> >
> S-curve accel/decel on R/C servos!  that would really make them
smooth. I'd done that for stepper motors, not for servos (of any
sort) yet. Just getting the transit time between the two points would
be a good place to start.  Wouldn't the closed loop inside the R/C
servo have eccel/decel already?
>


Not sure about accel/decell within the servos themselves, but it's no
big deal to implement velocity ramping on a PIC chip, and once you
have that, it's straightforward to modify the ramps to slow the
accel/decell on the 2 ends of the trajectory.

--- In SeattleRobotics@yahoogroups.com, Alan KM6VV <KM6VV@...> wrote:
>
> Subsumption is in the eye of the implementer!
>
> dan michaels wrote:
>
> ><snip>
> >You're right, there are different ways to view what subsumption
is.
> >All types essentially involve a "hierarchy" of control. Joe Jones,
> >for instance, seems to adhere to the most basic form, where
overall behaviors "emerge" out of interaction between very loosely-
coupled low-level behaviors.
> >
> >In my estimation, however, you need tighter coupling between low-
> >level behaviors with a quad, because the legs need to be
coordinated better, because the gaits are more dynamic than for
hexapods.
> >
> >
> >
> I might have said it before, but I think I see a great difference
> between "animal" types (bipeds/quadrapeds) and insects/spiders
> (hexapods+).  Maybe they are "wired" very differently?  Maybe we
can make a quadrapod walk with a simple insect gait, but it's not the
best, nor appropriate.  It would seem appropriate to handle them as
two different groups.
>
> Alan  KM6VV
>


For the "standard" walking gaits, Rbt Full of Berkeley sees those for
bipeds, quads, and hexapods [would also extend to octopods] as all
being totally analogous.

http://www.oricomtech.com/projects/leg-dyna.htm#Forc2

When you go to the quad gallops, however, then it's a different story.

Also, Peter doesn't quite seem to see it this way, but to me the quad
walk uses "waves" essentially identical to the hexapods and octopods,
except the #legs is different.

Polling, interrupt driven, event driven, event vectored, & state
machines are all tools for the engineer's tool bag along with many
other tools such as language, hardware, knowledge of different
micro's, etc. etc, etc.  They are all to be considered & implemented
where appropriate.  There is NO one right way for all designs.

--- In SeattleRobotics@yahoogroups.com, PeterBalch <PeterBalch@...>
wrote:
>>
> No. No. No. And again No. That doesn't work.
>
>

--- In SeattleRobotics@yahoogroups.com, PeterBalch <PeterBalch@...>
wrote:


>
> From: "dan michaels" <oric_dan@...>
> > As I see it, bipeds and quads solve the problem Peter is talking
> > about by using forward-spring in the legs, and also forward-
inertia of the CoG such that the frame is "falling-forward" onto the
new foot or support tripod.
>
> So gait 6 isn't statically stable?
>


My comment here was referring to the diagonal walk, not to the creep.
You'll notice that Jake does a short dynamic movement at positions 5
and 9, when switching tripods.

http://www.oricomtech.com/projects/leg-walk.htm#Walk2

--- In SeattleRobotics@yahoogroups.com, "don clay" <donclay@...> wrote:
>
> Polling, interrupt driven, event driven, event vectored, & state
> machines are all tools for the engineer's tool bag along with many
> other tools such as language, hardware, knowledge of different
> micro's, etc. etc, etc.  They are all to be considered & implemented
> where appropriate.  There is NO one right way for all designs.
>
> --- In SeattleRobotics@yahoogroups.com, PeterBalch <PeterBalch@>
> wrote:
> >>
> > No. No. No. And again No. That doesn't work.
> >
> >
>


Actually, Peter's comment here related to our mutual disagreement
about which greep gait sequences are stable. I don't buy his
explanation, for reasons I've given several times now, and he doesn't
buy mine, based upon his simulation program. Resolution doesn't seem
to be forthcoming.

Regards how to implement software, all of the listed methods work.
Peter's method for his 4-servo controller is perfectly fine, and is
what Scott Edwards has used for years with his commercial controller,
but it doesn't scale well to more than 8-servos.

I personally use timer interrupts for my servo chips, and this works
just fine - although there can be some possible latency issues when
interrupts occur simultaneously. To help deal with that, I prioritize
servicing within the ISR, and also double-check the flags within the
ISR, so at most there is only a couple of usec of possible skew. The
interrupt method is so efficient, only requiring about 5% of processor
time, that I was able to easily implement velocity ramping and full
CPG control in the same 20-mhz PIC chips.

Randy's devices do "everything" in one chip, servo control and main
programming, so he thinks Peter's method is wasteful. However, if you
have a "dedicated" servo chip, then this isn't so important.

--- In SeattleRobotics@yahoogroups.com, PeterBalch <PeterBalch@...>
wrote:
>

>
> In other words, the only way to make Gait 6 stable is to rely on
dynamics? It is not always statically stable?
>

As I've already said several times, I think creep gait 6 is always
statically stable, but the forward movement of the CoG also improves
it. As I've suggested before, look again at the cat and its beautiful
tripod, and which is doing Gait 6 [because that particular position
only ever occurs in gait 6], and think about what happens when the RR
leg comes down and the RF leg takes the next step.

http://www.oricomtech.com/projects/proj2/crp-stab.htm

PeterBalch replied: Tuesday, January 01, 2008 5:55 AM
> My programming time, on the other hand,
> is always expensive.

Granted.

However, when it comes to spending a few more minutes
programming to avoid buying 3x (or more) the amount of hardware
needed to get the same job done, a little extra programming can
be the less expensive path.

And, honestly, we're really not talking about economy of your
time, here. If so, you'd have bought the SSC, which costs
something like 20 minutes or less of your time, and avoided this
whole discussion.

Isn't the whole point of using a PIC is it is inexpensive, and
to avoid paying for more capable hardware? Isn't that the
essence of hobby robotics? Isn't that what drove your decision
to use tiny cheapo servos in your walker?

> I could get just as accurate timing with
> a tight loop. And it took less programming effort.

Well, you got by.

You didn't get accurate timing on the interval.

I'm not sure it took less effort.

It certainly took less thought.

> Also the interrupt would interfere with the
> servo timing. ... I can't use interrupts for
> the servos because they would interfere with
> the accurate timing of the phototransistors.
> I can't use interrupts for timing the
> phototransistors because they would interfere
> with the servos. ... but that's getting awfully
> complicated and has no advantage.

Here are the horns of a false dilemma. Yet another example of
"Why FSMs".

You can't use two separate interrupts without capture hardware
or they'll interfere, but that might take more expensive
hardware than your PIC has (I don't really know the PIC well
enough to be certain). So much for your time is more valuable
than the hardware.

You can't use two separate interrupts or they'll interfere,
without either capture hardware, or, state machine concepts.

It isn't complicated at all. In fact, the FSM approach uses the
same flow as your tight loops. But your tight loops use the
processor's Program Counter to keep the sequence in order. The
very same can be done with interrupts to keep the timing
sequences of the servo pulse and then the phototransistors in
order. Actually, both processes can share the same timer in the
same sense both processes share the same program counter in your
method.

> I "get it".

Pardon my saying so. The above example of what can't be done,
the two timings, doesn't speak well that you have gotten it.

> I know exactly how to write and use FSMs.

I have no doubt you know exactly how to write FSM's. The "and
use" part, I'm not yet convinced. You keep providing me fodder
examples to shoot down.

Peter I've grown to have a great fondness and respect for you
and your abilities in these discussions. I'm not calling you
stupid. You've already proven you can out program me on the PC.
However, I do think you're set in your ways, and not very open
to what is being presented, because like all of us, you're
comfortable with the way you've worked out doing things, and
don't like to be bothered with ideas that interfere with well
established ones.

My turn to go star wars. Peter, you have no idea the power of
the FSM side. Let go your bias. It is your destiny!

Randy
www.newmicros.com

PeterBalch said: Tuesday, January 01, 2008 5:55 AM
> As a biped, I find that if I'm falling forward, then either:
>
> 1. I put down my Flight foot a little earlier then normal and
> pick up my Stance foot a little earlier than normal so I can
> rush it forward sooner than I would otherwise do.
>
> 2. I lengthen the stride of the Flight foot so it goes down
> ahead of its usual position so it's ready to catch the fall
forward.
>
> Those two are exact opposites. Which one do I do? I'm not
sure.

I think it is all timing. I think we do both as bipeds (and
maybe one or two more strategies also), but it depends on stages
of progression. Also what we feel with our internal
"accelerometers".

> You shouldn't walk at the limit of what's
> possible for your body.

Absolutely. David Anderson made the point. Ever notice, perhaps
as a kid playing, if you start running down hill at full speed,
you can't stop? You have to be able to run just a bit faster, to
get your body under you, so you can lean back, to slow down. Get
faster than that reserve, you can either keep running, reach
level ground and slow down, or fall.

> Earlier, you were suggesting that recovery from forward
> falling could be done by speeding up or slowing down the gait
> timer. Are you now suggesting there's a separate reflex which
> is different from normal walking?

I think the action chosen depends on our acceleration senses. I
think there are a bunch of timings points where different
responses kick in. As I say, if we sense a sudden deceleration,
we run the gait in reverse hoping to "catch out balance. This
might happen when our flight foot lands very early, or we
experience a sudden both impact (tree branch, punch, an object
inpact on upper body). All these represent an impact which is
cause by a sudden acceleration in the opposite direction we are
walking.

OTOH if we don't get a change in acceleration, the flight foot
extends in front as normal. Now there's a brief window where we
expect a vertical acceleration from the foot fall. After that
moment of expected contact, if there is none, we go into a
backwards lean, a bending of the back knee, an attempt to throw
our weight back, in case we've stepped in a hole, or over a
precipice. In here I think there are several other bifurcations
of efforts beyond what I can explicitly pronounce, because we
are approaching extremis. And a great deal depends on what
sensations are coming from the advanced foot, contact or not.

> A single dual axis device can only measure the acceleration
> at one point in the robot. If you have two of them at
> different points then you can measure both overall
> linear-acceleration and overall rotational-acceleration. I
> think that might help distinguish feeling the same thing in
> two entirely different situations.

Could be. I was originally thinking of two in the horizontal
axis. Now I'm thinking we need one fore aft, and another up and
down, to facilitate walking. Measuring the vertical
accelerations, given we know our balance, and have learned our
body height, can tell us quite a bit about the rotation, without
specifically measuring it.

Randy
www.newmicros.com

--- In SeattleRobotics@yahoogroups.com, "Randy M. Dumse" <rmd@...>
wrote:
>

>
> You can't use two separate interrupts without capture hardware
> or they'll interfere, but that might take more expensive
> hardware than your PIC has (I don't really know the PIC well
> enough to be certain). So much for your time is more valuable
> than the hardware.
>
> You can't use two separate interrupts or they'll interfere,
> without either capture hardware, or, state machine concepts.
>


Not a big issue, if you're talking about a dedicated servo chip, as
opposed to one chip doing everything [like you use].

On my PIC servo controller, I use 2 sets of timer interrupts, plus a
UART interrupt. The ISR is tuned so that if 2 interrupts occur
simultaneously, and one is for the UART, there is only 1-usec of
extra latency on the 2nd interrupt request, and if both are timer
interrupts, then there is only about 2-usec of extra latency - in
both cases assuming the 2nd interrupt is for a timer. If all 3 occur
simultaneously with the UART slightly leading hte others, max extra
latency = about 3-usec.

This translates into worst case about (3us / 1000us) * 90deg = 0.27
deg of servo movement. Probably not enough to ever notice. And for a
walker, quite unimportant.

--- In SeattleRobotics@yahoogroups.com, "dan michaels" <oric_dan@...>
wrote:
>

>
> This translates into worst case about (3us / 1000us) * 90deg = 0.27
> deg of servo movement. Probably not enough to ever notice. And for a
> walker, quite unimportant.
>


Also, I think it was Gordon McComb that mentioned in the past that the
dead-band for a typical analog servo is about 4-usec.

dan michaels said: Tuesday, January 01, 2008 1:16 PM
> Not a big issue, ...
> there is only 1-usec of extra latency

My impression as well. The interrupt latency he worries about is
almost trivial, and could be handled with interrupt priorities.
But I play them as Peter pitches them.

And it's not really that it matters in my one-chip approach,
because I've got hardware handling the transitions in the PWM
for me, and it's accurate to 25nS. So as long as I get an update
every 20 mS, everthing on my system is as exact as can be.

Randy
www.newmicros.com

Hi Randy,:

>That's the basic idea behind IsoMax(TM). We have a scheduled
>(periodic) interrupt that should run faster than your fastest
>latency requirements. As I say, for mechanical systems, 100 Hz
>is pretty good. For electronic ones, you may want to run faster.
>
>This is the basic scan loop concept used in Relay Ladder Logic
>and PLCs.
>
>
Scan loop, that's a good name for it.

>In our language however, we gather all the waste cycles (those
>not used by the polling interrupts to check transitions and do
>actions) to give to the foreground routine which will usually
>communicate with the operator, which is ultimately the final
>waste of time, particularly if there is no operator there. A
>task can be autostarted here as well, such as data logging and
>progress following if desired. But if there is an operator, he
>can query memory, dump values, see what's going on
>interactively, while the real real-time program just keeps
>runing in the background. The operator can even add more
>programming while real-timer operations go on in the background
>without consequence.
>
>
I like the addition of a monitor program.  I run some commands through a
debug port, it wouldn't take much to add some "monitor" commands too.

>We started with the lowest common denominator, the scheduled
>(periodic) scanning. We can also run in interrupts, where the
>interrupt itself calls the FSM directly. And we've also
>implemented other versions, to allow layers of latencies. But we
>haven't released those codes yet. The next step has one layer
>for mechanicals, and another layer which can be much faster for
>faster processes like PID, and electronic communications.
>
>
Released these codes?  Like hidden commands?  the separate layers for
slower and faster services is useful.  Do you set task flags, or call
them directly from the ISR?

>
>
>>Waits.  "The rationale behind this method is a state is a
>>wait.".  Why a wait?  You give up a "tick" of the rate you
>>call your various state machines, but what's the wait?
>>
>>
>
>Well, follow the line of reasoning: A real-time program must
>wait for external synchronization. But rather than blocking, it
>can hand the wait off once it know the synchronizing event
>hasn't happened yet. (An interrupt event if the hardware
>supports this, or a timer event which can cause a periodic look
>at a rate higher than the latency requirements.) The wait is the
>state. State comes from Latin, Stare to stand. Nothing happens
>when you stand. And you "stand at ease" until there is something
>to do.
>
>
Perhaps one would call them "waiting points", or "gates"?  Even though
the program counter "can't get through the gate" but it doesn't stay in
the state, control passes back to the scan loop.  I hate to wait!

>Much much faster. Why compute the state each time? You knew what
>the new waiting state was going to be last time a transition
>happened. So why re-look it up every time the machine is called.
>Better to just go to the test that determines whether to leave a
>state or not. Again, set up the next wait vector on the way out
>of the current state.
>
>
Yeah, I can see the vectors being faster.  Although I like the
compartmentalization of a switch statement inside of a single function.
Data gets hidden, the FSM is complete within one function (fewer
data/control elements global).  But if you really need the speed...

>Then we also play some tricks in how we link the active machines
>so they ripple through their time slice as quickly as possible.
>
>
Do you have tricks to allow functions to be linked in at will?  Some
sort of dynamic linking?  Oh, you're possibly talking about calls and
returns.

>Randy
>www.newmicros.com
>
>

Alan  KM6VV

At 6:06 PM +0000 1/1/08, dan michaels wrote:

>As I've already said several times, I think creep gait 6 is always
>statically stable, but the forward movement of the CoG also improves
>it. As I've suggested before, look again at the cat and its beautiful
>tripod, and which is doing Gait 6 [because that particular position
>only ever occurs in gait 6], and think about what happens when the RR
>leg comes down and the RF leg takes the next step.
>
>http://www.oricomtech.com/projects/proj2/crp-stab.htm

So this is the first time I've taken a look at this page, because I wanted
to figure out what this whole "Gait 6" thing is.  While interesting, I
think it makes some bad assumptions.

1> that the movement of a foot is always 1/4 of the gait cycle.  There's no
reason that an animal's foot has to be held up in the air that long while
walking.  It's wasteful of energy and less stable.

2) that one foot landing and another being lifted are virtually
simultaneous.  Again, there's no reason for this.  If the "free" leg can
move quickly, surely it can be planted and stabilized before the next leg
comes up.

3) in animals, the rest of the body flexes, shifting the center of gravity
into the next triangle as needed.  That's where cats get that whole sinuous
walk.  (Heck, two-leggers do it too, if you've ever watched a woman's hips
while she walks....)

Given that, I think this whole business suffers from an over-simplified
problem definition.

Alan KM6VV said: Tuesday, January 01, 2008 1:46 PM
> I like the addition of a monitor program.  I run some
> commands through a debug port, it wouldn't take much to add
> some "monitor" commands too.

Yes, you will typically have the foregroun with plenty of room,
depending on your application, so making a monitor program to
watch the other processes can be done with idle time left over.

> Released these codes?  Like hidden commands?  the separate
> layers for slower and faster services is useful.  Do you set
> task flags, or call them directly from the ISR?

Rev. 2 of the language. Or perhaps Rev. 3. Only beta'd to a few.

Call them directly from a ISR. Actually you could say they are
the ISR.

> Perhaps one would call them "waiting points", or "gates"?
> Even though the program counter "can't get through the gate"
> but it doesn't stay in the state, control passes back to the
> scan loop.  I hate to wait!

Why not call them states? State machines have exist and were
understood long before digital computers came into being.

> Data gets hidden, the FSM is complete within one function
> (fewer data/control elements global).  But if you really need
> the speed...

On the contrary. As long as the state information is explicit,
and saved in protected variables, you can loose the program
counter in a crash, and reset right back to running state
machines without a hick-up at all. When you get to explicit
state information, you really do free yourself from crashes of
the processor and the like.

> Do you have tricks to allow functions to be linked in at
> will?  Some sort of dynamic linking?  Oh, you're possibly
> talking about calls and returns.

Yes, and no. Basically the machine structure is a list like the
native Forth language. So to add a machine you say "INSTALL
<name of machine>" and "UNISTALL <name of machine>" and the
first instance of it in the execution list is removed. It's not
as flexible as I had it in the past, but it works. We do give up
processor efficiency by running in an interactive high level
language. But primatives are often around 40 cycles. So what you
can normally do in assembly language on a PIC/AVR/8-bitter, you
can do as fast and as well on our processor in high level.

Randy
www.newmicros.com

I can see how quadrupeds can be described as having a "pair" of legs act
as a single leg of a biped, and hexapods as having three legs (tripod)
act as a single leg of a biped.  Even octapods are said to mimic bipeds
by having a pair of terapods.  But that only works for simple gaits, I'm
thinking.  After that, and with enough legs for ripple gaits (must be 6
or more legs, in my thinking), it the analogy starts to break down.

>For the "standard" walking gaits, Rbt Full of Berkeley sees those for
>bipeds, quads, and hexapods [would also extend to octopods] as all
>being totally analogous.
>
>http://www.oricomtech.com/projects/leg-dyna.htm#Forc2
>
>When you go to the quad gallops, however, then it's a different story.
>
>Also, Peter doesn't quite seem to see it this way, but to me the quad
>walk uses "waves" essentially identical to the hexapods and octopods,
>except the #legs is different.
>
>
>
It's hard to see a wave in only two legs on a side!  I think it takes at
least 3 legs (hexapod) to really have a ripple.  Otherwise, which way is
the ripple going?  We can't tell.  One of the reasons I see a chasm
opening up between quadrapods and hexapods.  And the intelligence to
drive these (in my mind) distinct groups varying greatly.

I haven't even begun to think about trots and gallops!  Certainly they
take more lower brain (do insects even have a lower brain?) to coordinate.

Alan  KM6VV

>>Perhaps one would call them "waiting points", or "gates"?
>>Even though the program counter "can't get through the gate"
>>but it doesn't stay in the state, control passes back to the
>>scan loop.  I hate to wait!
>>
>>
>
>Why not call them states? State machines have exist and were
>understood long before digital computers came into being.
>
>
Calling them states is fine.  I just couldn't see them as delays!

>
>
>>Data gets hidden, the FSM is complete within one function
>>(fewer data/control elements global).  But if you really need
>>the speed...
>>
>>
>
>On the contrary. As long as the state information is explicit,
>and saved in protected variables, you can loose the program
>counter in a crash, and reset right back to running state
>machines without a hick-up at all. When you get to explicit
>state information, you really do free yourself from crashes of
>the processor and the like.
>
>
But you'll have to insure the variables don't get reset!  It would be
nice to just pick up where one left off.

>
>
>>Do you have tricks to allow functions to be linked in at
>>will?  Some sort of dynamic linking?  Oh, you're possibly
>>talking about calls and returns.
>>
>>
>
>Yes, and no. Basically the machine structure is a list like the
>native Forth language. So to add a machine you say "INSTALL
><name of machine>" and "UNISTALL <name of machine>" and the
>first instance of it in the execution list is removed. It's not
>as flexible as I had it in the past, but it works. We do give up
>processor efficiency by running in an interactive high level
>language. But primatives are often around 40 cycles. So what you
>can normally do in assembly language on a PIC/AVR/8-bitter, you
>can do as fast and as well on our processor in high level.
>
>Randy
>www.newmicros.com
>
>
>
I recall that Forth had some interesting ways of handling threads.

Alan  KM6VV

--- In SeattleRobotics@yahoogroups.com, Alan KM6VV <KM6VV@...> wrote:
>
> I can see how quadrupeds can be described as having a "pair" of
legs act as a single leg of a biped, and hexapods as having three
legs (tripod) act as a single leg of a biped.  Even octapods are said
to mimic bipeds by having a pair of terapods.  But that only works
for simple gaits, I'm thinking.  After that, and with enough legs for
ripple gaits (must be 6 or more legs, in my thinking), it the analogy
starts to break down.
>


Yeah, I think Rbt Full was mainly comparing the more common gaits,
biped walk/run with quadruped trot with hexapod tripod gait.

Hence the quote:
===============
These measurements, plus the considerations mentioned above, have led
R.J. Full to conclude that, across the animal kingdom, legs and
locomotion work in an analogous fashion - namely, "... 1 human leg
works like 2 dog legs, 3 cockroach legs and 4 crab legs ...". Raibert
found a similar result relating quadruped gaits to a virtual biped
gait [Raib84].
===============


> >For the "standard" walking gaits, Rbt Full of Berkeley sees those
for bipeds, quads, and hexapods [would also extend to octopods] as
all being totally analogous.
> >
> >http://www.oricomtech.com/projects/leg-dyna.htm#Forc2
> >
> >When you go to the quad gallops, however, then it's a different
story.
> >
> >Also, Peter doesn't quite seem to see it this way, but to me the
quad walk uses "waves" essentially identical to the hexapods and
octopods, except the #legs is different.
> >
> >
> >
> It's hard to see a wave in only two legs on a side!  I think it
takes at least 3 legs (hexapod) to really have a ripple.  Otherwise,
which way is the ripple going?  We can't tell.  One of the reasons I
see a chasm opening up between quadrapods and hexapods.  And the
intelligence to drive these (in my mind) distinct groups varying
greatly.
>


They're similar in that they go rear-to-front in all those animals.
Chop 2 legs off the front or rear of the octopod and you have the
hexapod. Chop 2 more and you have the quadruped.

--- In SeattleRobotics@yahoogroups.com, Rich Chandler <rchandler@...>
wrote:
>
> At 6:06 PM +0000 1/1/08, dan michaels wrote:
>
> >As I've already said several times, I think creep gait 6 is always
> >statically stable, but the forward movement of the CoG also
improves it. As I've suggested before, look again at the cat and its
beautiful tripod, and which is doing Gait 6 [because that particular
position only ever occurs in gait 6], and think about what happens
when the RR leg comes down and the RF leg takes the next step.
> >
> >http://www.oricomtech.com/projects/proj2/crp-stab.htm
>
> So this is the first time I've taken a look at this page, because I
wanted to figure out that this whole "Gait 6" thing is.  While
interesting, I think it makes some bad assumptions.
>
> 1> that the movement of a foot is always 1/4 of the gait cycle.
There's no reason that an animal's foot has to be held up in the air
that long while walking.  It's wasteful of energy and less stable.
>
> 2) that one foot landing and another being lifted are virtually
> simultaneous.  Again, there's no reason for this.  If the "free"
leg can move quickly, surely it can be planted and stabilized before
the next leg comes up.
>


1+2 are essentially the same thing. Lifting one foot simultaneous
with planting the other is to me the limiting case. You can always
improve stability by having more overlap of feet on the ground, and
this has already been mentioned umpteen times previously.

The limiting case on that end would be never lift any feet, or more
practically, move each foot forwards just a tiny bit, but then it
would take forever to get anywheres.



> 3) in animals, the rest of the body flexes, shifting the center of
gravity into the next triangle as needed.  That's where cats get that
whole sinuous walk.  (Heck, two-leggers do it too, if you've ever
watched a woman's hips while she walks....)
>
> Given that, I think this whole business suffers from an over-
simplified problem definition.
>


That [body flex] is just adding another factor which improves
stability. When I cooked up the page, I was mainly looking at how it
might work with the fewest #of DOFs. If it works there, then you
should always be able to make it better by adding more.

>Yeah, I think Rbt Full was mainly comparing the more common gaits,
>biped walk/run with quadruped trot with hexapod tripod gait.
>
>Hence the quote:
>===============
>These measurements, plus the considerations mentioned above, have led
>R.J. Full to conclude that, across the animal kingdom, legs and
>locomotion work in an analogous fashion - namely, "... 1 human leg
>works like 2 dog legs, 3 cockroach legs and 4 crab legs ...". Raibert
>found a similar result relating quadruped gaits to a virtual biped
>gait [Raib84].
>===============
>
>
I like that observation!  Although I see it the other way around, 4 crab
work like 3 cockroach, which work like 2 dog, or 1 human.

>
>
>>>
>>>It's hard to see a wave in only two legs on a side!  I think it takes at
least 3 legs (hexapod) to really have a ripple.  Otherwise,
>>>which way is the ripple going?  We can't tell.  One of the reasons I
>>>see a chasm opening up between quadrapods and hexapods.  And the
>>>intelligence to drive these (in my mind) distinct groups varying
>>>greatly.
>>>
>>>
>
>They're similar in that they go rear-to-front in all those animals.
>Chop 2 legs off the front or rear of the octopod and you have the
>hexapod. Chop 2 more and you have the quadruped.
>
>
I see that.  But can it be all that simple?  Perhaps with quad "bugs".
I don't hear much about them.  But I think they may hop more then walk.

On another topic, do you run your hexapods on the BOT40?  C or ASM?   I
probably just didn't read far enough, but other then the boot loader, do
you supply a LIB to run servos, stepper motors, etc from the board?  The
bare board looks like it might be similar in size to the Quick flash
boards (4" x 4") that I'm using on my 'Bots.

Alan  KM6VV

--- In SeattleRobotics@yahoogroups.com, Alan KM6VV <KM6VV@...> wrote:
>
>
> >Yeah, I think Rbt Full was mainly comparing the more common gaits,
> >biped walk/run with quadruped trot with hexapod tripod gait.
> >
> >Hence the quote:
> >===============
> >These measurements, plus the considerations mentioned above, have
led
> >R.J. Full to conclude that, across the animal kingdom, legs and
> >locomotion work in an analogous fashion - namely, "... 1 human leg
> >works like 2 dog legs, 3 cockroach legs and 4 crab legs ...".
Raibert found a similar result relating quadruped gaits to a virtual
biped gait [Raib84].
> >===============
> >
> >
> I like that observation!  Although I see it the other way around, 4
crab work like 3 cockroach, which work like 2 dog, or 1 human.
>
> >
> >
> >>>
> >>>It's hard to see a wave in only two legs on a side!  I think it
takes at least 3 legs (hexapod) to really have a ripple.  Otherwise,
> >>>which way is the ripple going?  We can't tell.  One of the
reasons I
> >>>see a chasm opening up between quadrapods and hexapods.  And the
> >>>intelligence to drive these (in my mind) distinct groups varying
> >>>greatly.
> >>>
> >>>
> >
> >They're similar in that they go rear-to-front in all those
animals. Chop 2 legs off the front or rear of the octopod and you
have the hexapod. Chop 2 more and you have the quadruped.
> >
> >
> I see that.  But can it be all that simple?  Perhaps with
quad "bugs".  I don't hear much about them.  But I think they may hop
more then walk.
>


What I was indicating is that, like Full's comment above, the leg
sequences across such species are all analogous.



> On another topic, do you run your hexapods on the BOT40?  C or
ASM?   I probably just didn't read far enough, but other then the
boot loader, do you supply a LIB to run servos, stepper motors, etc
from the board?  The bare board looks like it might be similar in
size to the Quick flash boards (4" x 4") that I'm using on my 'Bots.
>
> Alan  KM6VV
>


I actually have about 5 or 6 different pcbs kicking around that I use
on my walkers, but they all use the same custom servo code, running
on either PIC 16F876 or 877 chips. It's written in assembler. [I
would say something like, I use assembler because all of the apps I
write involve real-time interrupts with precise timing situations,
but of course, that would only lead to dozens of people coming forth
and debating the veracity of such a statement, so I'll not say that].

You were talking about monitor code with Randy. Well, all of my
software starts with the same monitor code, and then I add various
custom code on top of that. I guess this is a carry-over from the
days when interpreters were common. Being an old Forth programmer, I
happen to like direct interactivity. Where others use simulators,
debuggers, and in-circuit emulators, I use a monitor sitting
underneath everything else.

To Whoever Suggested Buying Prefabbed Vehicle Vehicles From A Company Back
East, Were You Suggesting iRobot?  my ant would be a small fraction of its
size.  puzzles of how they get the radio control to work in caves.

   Kevin. . .  Is what you have one of those little yellow stair climbers?  I
Thought about that, although I think its maybe too small.  Isnt It Possible
They Have It Patented?




      
________________________________________________________________________________\
____
Never miss a thing.  Make Yahoo your home page.
http://www.yahoo.com/r/hs

Robert F. Scheer said: Monday, December 31, 2007 4:45 PM
> This idea of a CPLD or FPGA based hardware interface with a uC
hanging
> off the side sounds really good, especially if it GREATLY
reduces or
> eliminates the specialized uC programming we all have to
(learn to) do
> today.

Doesn't that sound good though.

> Kenneth Maxon wrote a good article on CPLD's here
> http://www.seattlerobotics.org/encoder/200006/cpld.htm

Good article. Still making my way through it now.

Randy

On Tuesday 01 January 2008 06:19:01 pm Alan KM6VV wrote:
> On another topic, do you run your hexapods on the BOT40?  C or ASM?

	 Dan (and Oricom Tech) makes the ooBOT II board I want to put an 18F4620,
18F4680, or 18F4685 on. :D I still want one of those boards, but other things
keep getting ahead of that. All I would have to do is make the ICSP type
header above the MCU socket permanently into a real ICSP header. ;)  I could
program the MCU right on the board in C or whatever other language is
available for PICs that I might want to use, and program/debug it using my
ICD2. ;)

	 8-Dale
--
I can handle complexity.  It's the simple things that confound me.
The Dynaplex Network - http://www.thedynaplex.org and
Hybrid Robotics - http://www.hybotics.com

John Palmisano said: Monday, December 31, 2007 3:34 PM
> On my more complicated projects I like to use multiple
> processors. One for each complex sensor, one for each
actuator, etc.
>
> My 'executive' processor only coordinates and makes/issues
> final decisions.
>
> This gives parallel power, but with linear implementation.
> Not unlike the human brain . . .

I know that approach is common wisdom, to put a micro per
sensor, but I don't necessarily agree with it. Many sensors
already have a micro in them. For instance, a SRF04 sonar
ranger, micro. So if you dedicate a micro per sensor, you have a
main processor talking to a micro that talks to a micro.

I suspect, but am not certain the same is true for the Sharp IR
Rangers. If not a micro, they have a pretty complex circuit in
there that times the pulses, and discriminates against IR
returns out of phase with their transmitted signal.

The CMPS03 has a micro in it for sure.

The GPS probably has a more powerful micro than most of us use
as our main brain.

Seems adding more micros is making the chain longer and longer,
and not solving the basic problem of getting the essense of the
data out and to where it needs to be considered.

I like to use a different standard. I like to wrap the problem
to where the necessary flow between a lower and upper processor
becomes like a human conversation. The example I gave earlier
was the upper brain says a short sentence, "like go this bearing
for this distance, and report back when done." Maybe about 10
bytes. And the reply is "Yes sir" in one byte. These exchanges
happen ever few seconds to a minute or two. About at the rate an
Officer of the Deck would give orders to his watch team, the
Helmsman, the Lee Helmsman, the Navigator, etc., on a ship. Or
maybe a bit faster, if the robot is faster turning than a ship.
;) But low duty cycle compared to USB rates.

Randy
www.newmicros.com

Yes, I like monitors!  And usually a printf() will get me any additional
info I need.

ASM was fine on PCs, but I don't care much for it on PICs.  But it can make
fast and tight code. But there is no need to start any wars. ;>)

Sounds like you've got a useful servo code lib if you can reuse it all the
time!  I need to get working on mine.

Alan  KM6VV


> > On another topic, do you run your hexapods on the BOT40?  C or
> ASM?   I probably just didn't read far enough, but other then the
> boot loader, do you supply a LIB to run servos, stepper motors, etc
> from the board?  The bare board looks like it might be similar in
> size to the Quick flash boards (4" x 4") that I'm using on my 'Bots.
> >
> > Alan  KM6VV
> >
>
>
> I actually have about 5 or 6 different pcbs kicking around that I use
> on my walkers, but they all use the same custom servo code, running
> on either PIC 16F876 or 877 chips. It's written in assembler. [I
> would say something like, I use assembler because all of the apps I
> write involve real-time interrupts with precise timing situations,
> but of course, that would only lead to dozens of people coming forth
> and debating the veracity of such a statement, so I'll not say that].
>
> You were talking about monitor code with Randy. Well, all of my
> software starts with the same monitor code, and then I add various
> custom code on top of that. I guess this is a carry-over from the
> days when interpreters were common. Being an old Forth programmer, I
> happen to like direct interactivity. Where others use simulators,
> debuggers, and in-circuit emulators, I use a monitor sitting
> underneath everything else.

--- In SeattleRobotics@yahoogroups.com, "Alan KM6VV" <KM6VV@...>
wrote:
>
> Yes, I like monitors!  And usually a printf() will get me any
additional info I need.
>
> ASM was fine on PCs, but I don't care much for it on PICs.  But it
can make fast and tight code. But there is no need to start any
wars. ;>)
>
> Sounds like you've got a useful servo code lib if you can reuse it
all the time!  I need to get working on mine.
>
> Alan  KM6VV
>


Actually, my servo chips are all pretty much dedicated as servo
functions only, so I don't have a library that I can dump into any
general-purpose chip. That would not be very realistic, I think,
considering the timing requirements on the servo pulses.

OTOH, the core monitor code is easier to treat as a standard lib, and
it's easy to start off every new application using it as the
foundation. Then simply start adding custom modules on top of that.
The new custom code can all run in real-time, and the monitor RAM
dump command can act as a large printf() statement to view all
variables simultaneously.

--- In SeattleRobotics@yahoogroups.com, Alan KM6VV <KM6VV@...> wrote:
>
>
> >Yeah, I think Rbt Full was mainly comparing the more common gaits,
> >biped walk/run with quadruped trot with hexapod tripod gait.
> >
> >Hence the quote:
> >===============
> >These measurements, plus the considerations mentioned above, have
led R.J. Full to conclude that, across the animal kingdom, legs and
> >locomotion work in an analogous fashion - namely, "... 1 human leg
> >works like 2 dog legs, 3 cockroach legs and 4 crab legs ...".
Raibert found a similar result relating quadruped gaits to a virtual
biped
> >gait [Raib84].
> >===============
> >
> >
> I like that observation!  Although I see it the other way around, 4
crab work like 3 cockroach, which work like 2 dog, or 1 human.
>


BTW, this was all discussed several months ago before you got into
the conversations, but I have been working on a new quad, named Poco.
I **finally** built and operated the first leg yesterday, while
everyone else was celebrating college football bowl day. I've been
gathering parts and making plans for months. Doing mechanical stuff
is like getting root-canals for some of us.

In any case, I was looking at the Toejammer design for sometime, and
thought the hip rotator mechanism might be good on a quad. Peter has
talked about adding the fore-aft axis to aid turning, while I'm
trying the vertical rotation axis for this. It's similar to how
humans do most turns. While standing straight, rotate the foot into
the new direction, and step forward, etc.

So, I scrapped Toejammer [R.I.P.] to build the front end of Poco. The
idea is to attach regular 2-DOF legs to the frame with the hip
rotators. We'll see how this goes. Basically, the idea is to get
something similar to the dogs turning in these pictures.

http://www.oricomtech.com/projects/leg-walk.htm#Turn2

To a large extent, the dog turns by angulating its entire body,
and "crossing-over" the front foot, while Poco will turn by rotating
the foot like a human, to produce approximately the same effect. The
trick will probably be to make sure the CoG stays inside the
stability triangle.