[Dprglist] Question on ballistic behaviours

[Karim Virani]

Hey Murray,

By ballistic behavior, I'm assuming you're not talking about projectile
motion, but a behavior that has a natural "trajectory to completion." In my
teams we casually call those set and forget behaviors. But we think of
those as one end of a continuum of inter-dependency/interuptability.

Regarding the question about having only one behavior running at a time -
that can't work for my teams. By definition their runs are time-limited and
the robots need to be doing things simultaneously where possible. It's also
more interesting that way.

The problem/opportunity is in looking at the robot as a collection of
interfering/collaborating subsystems. Regardless of whether you think of
the control problem from a top-down or a bottom up approach, what you have
to map out are the states and interactions of your subsystems. The more
complicated your robot, the harder this becomes. My team usually builds a
kinematic model of the robot to help manage the physical interactions and
potential collisions. But that's just a starting place and things will get
messy when you start composing behaviors from other behaviors, some of
which are interruptible under various conditions and some of which span
potentially interfering subsystems under different operating modes.

You can probably get away with a single behavior manager (your term) if
you're restricting your implementation to navigation - effectively
chassis-only behaviors. It certainly makes sense that for a given virtual
actuator (like a pair of motors in a differential drive configuration)
there should only be one behavior directing them at a time.

But that might be an overly restrictive version of the behavior concept. In
our bots, behaviors that map to control over actuators within a particular
subsystem are called Articulations. We call them that because we tend to
think of the joints, rotations, translations and transitions as what the
Articulations want to achieve (vs. low level motor control). We indeed will
typically have a single Articulation active per subsystem. But that doesn't
mean that we think of Articulations as the only collection of behavior-like
constructs in our code. We also have higher level behaviors that coordinate
behaviors of multiple subsystems. And we have behaviors that don't control
actuators, but do control other kinds of goal-seeking. And finally there
are the emergent behaviors that aren't explicitly coded. I intentionally
advise my students to avoid naming any class "Behavior" so they don't
conflate the concept with the implementations of the day.

Long story short, I don't think there is a "right design", though there are
surely many poor ones. It doesn't matter as long as the sorta-good designs
progress to something better.

Best,

karim

On Fri, Jun 25, 2021 at 5:36 AM Murray Altheim via DPRGlist <
dprglist at lists.dprg.org> wrote:

> Hi,
>
> I'm at the point where I've got the basic message event loop up and running
> such that sensors and other even sources can fire messages onto the message
> bus, and various subscribers can listen for specific events and act upon
> them. E.g., the MotorSubscriber is interested in motor-related events. I'm
> now starting to implement the ActionSubscriber, where I've got a "roam"
> action that looks for an event-idle situation and directs the robot to
> begin roaming around. As an exercise I'm planning to implement this as a
> sample ballistic behaviour.
>
> So I'm now beginning to implement the groundwork for the ballistic
> behaviours, figuring there'll eventually be a few of them, so I'll have
> a BehaviourManager class (jokes welcome) that makes sure only one ballistic
> behaviour is running at a time - they'll be prioritised so that a lower
> priority ballistic behaviour can't override a higher priority one.
>
> Does this make sense? I.e., does it make sense to permit more than one
> ballistic behaviour to be executing at the same time, or should there by,
> by definition, only one?
>
> I'm asking this to help me think through what the right design might look
> like.
>
> The code in question is the KROS-Core library I posted a link to the other
> day:
>
>     https://github.com/ifurusato/kros-core
>
> [Anyone can download and install this even on a laptop (no robot required),
> running the pub_sub_test.py.]
>
> Thanks for any help,
>
> Murray
>
> ...........................................................................
> Murray Altheim <murray18 at altheim dot com>                       = =  ===
> http://www.altheim.com/murray/                                     ===
> ===
>                                                                     = =
> ===
>      In the evening
>      The rice leaves in the garden
>      Rustle in the autumn wind
>      That blows through my reed hut.
>             -- Minamoto no Tsunenobu
>
> _______________________________________________
> DPRGlist mailing list
> DPRGlist at lists.dprg.org
> http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dprg.org/pipermail/dprglist-dprg.org/attachments/20210626/16302d3f/attachment.html>