More actor components and follow plugin #157
Conversation
Signed-off-by: Louise Poubel <louise@openrobotics.org>
Codecov Report
@@ Coverage Diff @@
## master #157 +/- ##
==========================================
+ Coverage 65.42% 65.77% +0.35%
==========================================
Files 128 128
Lines 6287 6297 +10
==========================================
+ Hits 4113 4142 +29
+ Misses 2174 2155 -19
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Looks good! I have a question about the high level behavior, I have seen that the Z axis is usually ignored which means that the actors will only follow objects in the XY plane (i.e. attached below).
This would make the behavior in cases where the world is not a perfectly flat plane a bit tricky, let's say you have a robot going up a slope and a human following it, if I understand correctly the human will keep walking forward, probably going through the plane, while the robot goes up and it will end up in a configuration similar to the screenshot.
On the other hand though, I can see how if you introduced always following Z it could require some tuning in the case of flat planes, i.e. if you set the animation root node of the example to follow the root node of the cube object the actor could be partially floating / compenetrating the plane depending on the relative position of the two root nodes.
What do you think?
| // Time delta | ||
| std::chrono::duration<double> dtDuration = _info.simTime - | ||
| this->dataPtr->lastUpdate; | ||
| double dt = dtDuration.count(); |
There was a problem hiding this comment.
More a curiosity here, can we just use _info.dt or is there any benefit in calculating the dt manually?
There was a problem hiding this comment.
Yeah good point. I was planning to throttle this system so it doesn't run at 1000 / 500 Hz. I'll go ahead and do that.
Yeah you're right, that's the current assumption. I can't think right now of a solution that is generic enough though. The trick is how to choose the Z for the actor. I think the ideal solution would involve detecting the closest point on the ground below the actor and keeping a fixed* distance to that. Think for example of an actor following a drone - the drone may go up and down but the actor should keep the same Z on flat ground. Let me know if you have a specific use case and I can try to at least support that 🤔 * Depending on the animation even a fixed distance may be wrong though. |
Signed-off-by: Louise Poubel <louise@openrobotics.org>
That was actually a feature on ServiceSim. If the robot moved too fast, the human would get lost and stop following. It wouldn't restart following until the robot asked to be followed again. Since this port doesn't have a transport interface, there's no way to get the actor to follow again. I realize this isn't very useful. So I changed the implementation so that the actor always follows if within range: e9588c2 |
Addresses part of #91.
Add a couple of components:
AnimationNameAnimationTimeAlso added the
FollowActorplugin as a useful* example, which is a port of servicesim::FollowActorPlugin, with a subset of functionalities:<target>)* Actually useful, unlike the examples/plugin/command_actor I had been adding.
I looked into calculating it automatically inside rendering like we do when using
interpolate_x. That approach involves calculating the average speed of the animation based on the start and end positions of the root node. That's only an approximation though. Plugin developers have more flexibility if they can directly setAnimationTimeat each time step. That's more flexible but also more work. I took that route here mainly because that interface was exposed in Gazebo-classic's Actor::SetScriptTime, which I saw used on at least one other plugin besides ServiceSim's.In the future, we could look into exposing the skeleton information to all systems as a component. We need to be careful when the
SceneManageris only on the client though.