1
$\begingroup$

I've been working on a module that takes in planar poses $\begin{bmatrix} x_{t_{k}} & y_{t_{k}} & \theta_{t_{k}}\end{bmatrix}^{T}$ and spits out expected robot states $\begin{bmatrix} x_{t_{k}} & y_{t_{k}} & \theta_{t_{k}} & \dot{x}_{t_{k}} & \dot{y}_{t_{k}} & \dot{\theta}_{t_{k}} \end{bmatrix}^{T}$. Essentially, I'm giving the velocity I expect the robot to reach at each pose.

I've been looking for the proper terminology for a module like this, both so I can write more readable code and so that I can do a better literature search. What would this kind of thing be called?

Thanks!

$\endgroup$
  • $\begingroup$ Well, this $\begin{bmatrix} x_{t_{k}} & y_{t_{k}} & \theta_{t_{k}}\end{bmatrix}^{T}$ is part of the robot's state which represents the state's pose. Would you please elaborate a bit about the term you're looking for? $\endgroup$ – CroCo Aug 29 '17 at 16:44
  • $\begingroup$ The pose is a subset of the whole robot state, but my robot's essentially getting a list of poses that it needs in order to generate full robot states (pose + velocity). Would that be a state generator? A pose-to-state converter? A state planner? $\endgroup$ – Nick Sweet Aug 29 '17 at 16:52
  • $\begingroup$ The desired pose?! $\endgroup$ – CroCo Aug 29 '17 at 16:55
  • $\begingroup$ Unless there's two different terminologies, I've only ever heard of robot pose as simply position and orientation - not linear and angular velocity (which, at least in the ROS community, would be a Twist). In my problem, the state is a combination of pose and twist. $\endgroup$ – Nick Sweet Aug 29 '17 at 17:02
  • $\begingroup$ So you are making a full state observer (an optimal version of that is also known as a Kalman filter)? $\endgroup$ – fibonatic Aug 30 '17 at 14:25
1
$\begingroup$

It is a little tough to tell what you are asking because of the limited information. It would be helpful if you would show how these vectors fit in your control scheme. However, I'll start an answer and maybe we can arrive at the one you need.

If you are strictly talking about the positions and velocities without regard for how to control them to achieve those poses, then you are just describing differential, or velocity, kinematics. The arrangement into new pose vectors isn't meaningful in this case.

If you are trying to do this to achieve positional via points which are arrived at with a certain velocity, you may benefit from studying velocity control. Off the top of my head I believe Hollerbach had some seminal work in this, but I could be mistaken.

If you are actually concerned with the robot's position and velocities as states to feed into a controller, then you should study state space control. @Chuck has answered some questions with excellent descriptions of state space, and there are numerous other public sources available.

EDIT BASED ON OP's COMMENT

Thanks for describing the scheme. It would be best to put that into your question since comments can disappear eventually.

You are describing an aspect of robotic controls that is generally called path planning, trajectory generation, or sometimes trajectory planning. Purists will differentiate between path planning and trajectory planning in that path planning refers to the geometry of the path (in operational and/or configuration space) only, whereas trajectory planning includes a time element. So your approach is really about trajectory planning, although the literature doesn't always separate the two like that.

The literature in this field includes planning for robotic manipulators, redundant robots, and mobile robots. Often the path planning problem includes avoiding obstacles or optimizing some run-time criterion. However, there are also many earlier papers which describe the planning aspect of manipulators without regard to obstacles. Frequently those papers describe time-optimal methods for achieving target trajectories.

You may want to start your research looking for work by Bruno Siciliano.

| improve this answer | |
$\endgroup$
  • $\begingroup$ Here's the high level planning/control scheme: 1) Generate a list of waypoints (x, y). 2) Add orientations (x, y, theta) to those waypoints to generate planned robot poses. 3) Add velocities to those robot poses (x, y, theta, x_dot, y_dot, theta_dot) to constrain the robot dynamics. 4) Generate trajectory splines to translate discrete states into continuous state profiles (not simply interpolate between them). 5) Perform PID control over the trajectory splines to generate robot commands. You're right that my question would relate to a kinematics generation module -- a "Kinematic planner"? $\endgroup$ – Nick Sweet Aug 30 '17 at 17:21
  • 1
    $\begingroup$ Thanks for the answer! I guess I was a little closed-minded in thinking that a trajectory planner would only work on continuous trajectories, but I could see how a trajectory planner would also subsume the discrete states from which the trajectories were generated. Thanks for helping me work out the nomenclature. $\endgroup$ – Nick Sweet Aug 30 '17 at 19:01
0
$\begingroup$

It depends on how you compute those velocity coordinates.

For example, if you compute the velocity based on the information about previous (and probably future) poses, it is called interpolation. Literature in this area focuses mainly on polynomial or spline interpolation. But if you do the search, the papers likely appear under the term trajectory generation.

If there are also sensor data and other stuff coming in real-time that you take into account, you might want to search on-line trajectory generation.

If you codes are for mobile robots, you might also want to study nonholonomic constraints as well. (The constraints basically say that an ordinary car cannot move sideways, etc.) So that you can generate achievable velocity.

| improve this answer | |
$\endgroup$
  • $\begingroup$ This is a step before interpolation. I'll be interpolating these states into trajectories (basing off of Sprunk 2008 [1] - from one of Burgard's students). I suppose I could fold in the poses to trajectories directly without going through the intermediary pose + velocity state model, but something smells bad about that approach. [1] www2.informatik.uni-freiburg.de/~lau/students/Sprunk2008.pdf $\endgroup$ – Nick Sweet Aug 30 '17 at 17:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.