Add basic behaviour tree-based API #636
Conversation
| import py_trees.composites | ||
| import py_trees.common | ||
|
|
||
| class Road(py_trees.composites.Sequence): |
There was a problem hiding this comment.
I would expect that the road will only contain cars, is that correct? I don't know if in a near future we could support "damageable" roads which could modify something else. So I think that roads could inherit from the parallel composite instead of sequence, using SuccessOnAll or SuccessOnOne policy. We should specify how a car could enter to a FAILURE state later on and go back to this composite
There was a problem hiding this comment.
That sounds pretty reasonable to me. I only started out with a Sequence out of simplicity. @stonier thoughts?
hidmic
force-pushed
the
hidmic/py_trees-based-api
branch
from
8d28532 to
19c9962
Compare
python/delphyne/behaviours/agents.py
Outdated
| self.nominal_speed = nominal_speed | ||
|
|
||
| def setup(self, *, builder): | ||
| road_index = self.parent.road_geometry.ById() |
There was a problem hiding this comment.
Playing around with the trees, I faced with one problem. This assumes that the parent is a road. I was adding a decorator to one of the cars and it crashed, since the parent now is a decorator, not a Road. I think that we should start specifying which variables should be exposed in a blackboard
There was a problem hiding this comment.
That's fair point. Feel free to update this PR with the changes necessary.
|
|
||
| ROAD_GEOMETRY_KEY = 'road_geometry' | ||
| SIMULATION_KEY = 'simulation' | ||
| LANE_PROVIDER_KEY = 'lane_provider' |
src/common/signal_guard.cc
Outdated
|
|
||
| SignalGuard::~SignalGuard() { | ||
| SignalGuard::allow_signal_handling = false; | ||
| SignalGuard::signal_guards[signum_] = prev_signal_guard_; |
There was a problem hiding this comment.
Can we have a scenario where we construct one signal, and then we destroy another one so the atomic boolean turns to true and another thread tries to do something funny in the middle?
There was a problem hiding this comment.
This is not thread-safe, not by a long shot. But drake isn't thread-safe either and a multithreaded simulation is not a deterministic one so I'd figured it wouldn't be a problem. We can document it accordingly though, I didn't :/
There was a problem hiding this comment.
If it's not thread safe, what's the point of using an atomic bool then? isn't pointless?
There was a problem hiding this comment.
Oops, I didn't reply. No, it's not pointless. Signals still arrive asynchronously and may be served concurrently.
|
Nevermind merge conflicts, we have an issue guys. Delphyne's |
hidmic
force-pushed
the
hidmic/py_trees-based-api
branch
from
72ee74f to
7aa73ee
Compare
Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>
Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>
Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>
Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>
Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>
Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>
* Add blackboard helper and multilane road class * Add simulation as a key of the blackboard * Get the road geometry from the agent simulation builder * Add support for randomly placed cars in lanes (#639)
Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>
Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>
hidmic
force-pushed
the
hidmic/py_trees-based-api
branch
from
7aa73ee to
144ff0b
Compare
Precisely what the title says. This is a first draft PR to support the bare minimum functionality necessary to start migrating existing demos.
Connected to #634.