[Dprglist] First BBR implementation and some questions
David P. Anderson
davida at smu.edu
Sun Oct 31 22:19:46 PDT 2021
Karim,
How flattering! :)
Well, yes. But this gets in deep.
Most of the subsumption machine is reactive, even the navigation.
Ballistic behaviors are the exception. They can of course be subsumed
like any others. The question becomes what happens to them while
subsumed? Remember from their point of view they are continuing to run
and output controls to the robot. They are ballistic.
So suppose you have a ballistic behavior to rotate in place some number
of degrees. Half way through the robot bumps into something. So the
ballistic bumper behavior subsumes the rotate behavior and moves the
robot to a new position and angle, and releases control. So what is the
correct action for the ballistic rotate behavior at that point? You
really need to start over and recalculate the angle, you can't just
complete the angle you have ballistically , or you'll be pointing in the
wrong direction.
Further during the bump behavior the rotate continued to run and output
it's commands, but it was subsumed. So depending on how long the
bumper behavior took, the ballistic maneuver may or may not have
actually completed before the control is even returned to it..
This is what is meant by "ballistic behaviors can't be interrupted," the
source of so much confusion. It's not that they can't be. It's that
it screws them up. In that sense they break the subsumption paradigm.
Recalling that this is all in the context of subsumption, and not
perhaps more generalized use of the terms.
I've found the best option is usually just to abort. So the rotate
aborts if subsumed. Let higher levels start things over if they want.
But this only re-enforces, I think, that ballistic behaviors in the
context of subsumption are differentiated from servoing behaviors in
that they continue executing after the signal that triggered them has
ceased. (and they should generally be avoided.)
The subsumption of servoing behaviors does not have this problem
cheers!
dpa
On 10/31/21 11:00 PM, Karim Virani wrote:
> I agree, that's the problem. Crossover. Subsumption is not the only
> architecture in use. Behavior-based is a broad concept and there are
> many arbitration schemes that can be employed. I was trying to
> carefully constrain my comments to "my vote", in other words, just my
> own words, my own opinion - not trying to represent or denigrate any
> other point of view or approach.
>
> Maybe the term "ballistic behavior" belongs exclusively to subsumption
> architectures ... and I've mistakenly heard it applied more broadly.
> I'm certainly no expert in subsumption. We use explicit state machines
> to control our double-digit DOF robots. So I try not to comment
> directly on subsumption.
>
> But It can be confusing. When you google:
>
> "ballistic behavior" robot subsumption
>
> The first thing that comes up is this excerpt from an expert in Dallas:
>
> Ballistic behaviors *cannot be subsumed*: they must run to completion.
> 2. Ballistic behaviors are therefore usually assigned highest priority.
>
> Yup, the excerpt stops right there even though you continue in your
> article:
>
> 3. Ballistic behaviors can, however, be aborted.
>
> In fact, abort is really the only reasonable response of a ballistic
> task when subsumed. For the SR04 robot, the only task that can subsume
> a ballistic bumper behavior, which is the highest priority behavior,
> is another ballistic bumper behavior.
>
>
> So can they be subsumed or not? The language is tricksy.
>
> http://www.geology.smu.edu/dpa-www/robo/subsumption/#:~:text=Ballistic%20behaviors%20cannot%20be%20subsumed,therefore%20usually%20assigned%20highest%20priority
> <http://www.geology.smu.edu/dpa-www/robo/subsumption/#:~:text=Ballistic%20behaviors%20cannot%20be%20subsumed,therefore%20usually%20assigned%20highest%20priority>.
>
>
> On Sun, Oct 31, 2021 at 9:59 PM David P. Anderson via DPRGlist
> <dprglist at lists.dprg.org <mailto:dprglist at lists.dprg.org>> wrote:
>
> Well, Karim, now that you mention it...
>
>
> On 10/31/21 5:26 PM, Karim Virani via DPRGlist wrote:
>> I agree with Doug, you should never have blocking code unless you
>> can dedicate a separate thread to it apart from your main loop's
>> thread.
>>
>> And not to start up the whole debate again, I personally vote
>> that there is no use for ballistic behaviors. I treat them as an
>> academic construct. There are plenty of uses of
>> objective-oriented and terminating behaviors - including those
>> where the objective is to last for a certain amount of time. But
>> they should still be interruptible and cancellable by higher
>> priority behaviors.
>
> I believe this is a misunderstanding of what ballistic behaviors
> are in the context of subsumption. For some reason the idea has
> taken root that what makes a behavior ballistic is that it for
> some reason cannot be interrupted. That is a red herring.
> What make a behavior a ballistic behavior */_in the context of
> subsumption_/* is that it continues to execute after the signal
> that triggered it has ceased.
>
> That's all.
>
> I don't understand why such a simple concept has turned out to be
> so hard to communicate. I consider this a major failing on my part.
>
> cheers!
>
> David
>
>
>
>>
>> On Sun, Oct 31, 2021 at 5:08 PM Doug Paradis via DPRGlist
>> <dprglist at lists.dprg.org <mailto:dprglist at lists.dprg.org>> wrote:
>>
>> Kumar,
>> I always pass through the loop. So a 1 sec backwards
>> maneuver would use a loop counter with a disengage value of
>> 50 for a loop time of 20 mS. I am not using a multitasking
>> framework, which opens up other possibilities.
>>
>> Regards
>> Doug P.
>>
>> Sent from my iPhone
>>
>>> On Oct 31, 2021, at 4:54 PM, Thalanayar Muthukumar via
>>> DPRGlist <dprglist at lists.dprg.org
>>> <mailto:dprglist at lists.dprg.org>> wrote:
>>>
>>> https://youtu.be/fuFamNWyXc4
>>> <https://secure-web.cisco.com/12R-xW2iM6X1mtZ6lGWZ2cU_V7WhrcVFmrYppQ5_RFJAtuHcumxuYD4t8YW_aGm011_ipOLIKUMPmlNlXLKe0mDeZ5NILZd__YuRF_kKIzyxN8EiJErAuYE-OcebwmywmyJ7SoBG9yB3Oyna9Z9RUY7kwZdTuI-sO3UWkVWgVNhYiwT1_tphO9qAaoFdwYrgHVEynVcBz9QhIC_xYutA9B-8OhKAWWEGvh-8EqTFHmW8H5ZsvYDMLEZNwPag9e3p4bO7y-E8y4CehSNJJRVtWHgi8hUB2z2KYLDpQOUR9fxk/https%3A%2F%2Fyoutu.be%2FfuFamNWyXc4> (~15
>>> sec)
>>>
>>> 20 times per sec
>>> - default behavior - go straight forward, green headlights
>>> - higher priority behavior - light sensed, turn left, red
>>> headlights
>>>
>>> My understanding of BBR is that there should be no state
>>> maintained.
>>>
>>> Question - If we trigger a ballistic behavior (e.g. go
>>> straight backward for one sec), is it ok to not return to
>>> the loop every 50 msec?
>>>
>>> Or is it preferable to maintain state and count 20 times for
>>> getting duration of 1 sec?
>>>
>>> Regards.
>>> - Kumar
>>>
>>>
>>>
>>> Sent from my iPhone
>>> _______________________________________________
>>> DPRGlist mailing list
>>> DPRGlist at lists.dprg.org <mailto:DPRGlist at lists.dprg.org>
>>> http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org
>>> <http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org>
>> _______________________________________________
>> DPRGlist mailing list
>> DPRGlist at lists.dprg.org <mailto:DPRGlist at lists.dprg.org>
>> http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org
>> <http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org>
>>
>>
>> _______________________________________________
>> DPRGlist mailing list
>> DPRGlist at lists.dprg.org <mailto:DPRGlist at lists.dprg.org>
>> http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org <http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org>
> _______________________________________________
> DPRGlist mailing list
> DPRGlist at lists.dprg.org <mailto:DPRGlist at lists.dprg.org>
> http://lists.dprg.org/listinfo.cgi/dprglist-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/20211101/08683721/attachment.html>
More information about the DPRGlist
mailing list