<div dir="ltr"><br>Hey Murray,<br><br>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. <br><br>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.<br><br>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.<br><br>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. <br><br>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. <br><br>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.<br><br>Best,<br><br>karim<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 25, 2021 at 5:36 AM Murray Altheim via DPRGlist <<a href="mailto:dprglist@lists.dprg.org">dprglist@lists.dprg.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
I'm at the point where I've got the basic message event loop up and running<br>
such that sensors and other even sources can fire messages onto the message<br>
bus, and various subscribers can listen for specific events and act upon<br>
them. E.g., the MotorSubscriber is interested in motor-related events. I'm<br>
now starting to implement the ActionSubscriber, where I've got a "roam"<br>
action that looks for an event-idle situation and directs the robot to<br>
begin roaming around. As an exercise I'm planning to implement this as a<br>
sample ballistic behaviour.<br>
<br>
So I'm now beginning to implement the groundwork for the ballistic<br>
behaviours, figuring there'll eventually be a few of them, so I'll have<br>
a BehaviourManager class (jokes welcome) that makes sure only one ballistic<br>
behaviour is running at a time - they'll be prioritised so that a lower<br>
priority ballistic behaviour can't override a higher priority one.<br>
<br>
Does this make sense? I.e., does it make sense to permit more than one<br>
ballistic behaviour to be executing at the same time, or should there by,<br>
by definition, only one?<br>
<br>
I'm asking this to help me think through what the right design might look<br>
like.<br>
<br>
The code in question is the KROS-Core library I posted a link to the other<br>
day:<br>
<br>
<a href="https://github.com/ifurusato/kros-core" rel="noreferrer" target="_blank">https://github.com/ifurusato/kros-core</a><br>
<br>
[Anyone can download and install this even on a laptop (no robot required),<br>
running the pub_sub_test.py.]<br>
<br>
Thanks for any help,<br>
<br>
Murray<br>
<br>
...........................................................................<br>
Murray Altheim <murray18 at altheim dot com> = = ===<br>
<a href="http://www.altheim.com/murray/" rel="noreferrer" target="_blank">http://www.altheim.com/murray/</a> === ===<br>
= = ===<br>
In the evening<br>
The rice leaves in the garden<br>
Rustle in the autumn wind<br>
That blows through my reed hut.<br>
-- Minamoto no Tsunenobu<br>
<br>
_______________________________________________<br>
DPRGlist mailing list<br>
<a href="mailto:DPRGlist@lists.dprg.org" target="_blank">DPRGlist@lists.dprg.org</a><br>
<a href="http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org" rel="noreferrer" target="_blank">http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org</a><br>
</blockquote></div>