You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be useful to have visibility on how points in the source path are remapped into the retimed path, for the purpose of path debugging.
For example, let's say you have a robot path comprised of several key waypoints. The path is retimed using toppra and sent to the robot. Assuming we can get the elapsed time from the robot while it is running the retimed path, this time could be used to work out which key waypoint in the source path the robot is currently executing for the purposes of debugging and tweaking the source path.
This information is available in both the ConstAccel and the Spline parametrizers internally as m_ts member variable but don't expose them publicly.
Describe the solution you'd like
A way to access m_ts, preferably in the toppra::Parametrizer interface, so we don't have to worry about which parametrizer is used.
Describe alternatives you've considered
We could have a separate class which works out these times and exposes them, but this mapping presumably depends on the parametrizer used.
It would be useful to have visibility on how points in the source path are remapped into the retimed path, for the purpose of path debugging.
For example, let's say you have a robot path comprised of several key waypoints. The path is retimed using toppra and sent to the robot. Assuming we can get the elapsed time from the robot while it is running the retimed path, this time could be used to work out which key waypoint in the source path the robot is currently executing for the purposes of debugging and tweaking the source path.
This information is available in both the
ConstAccel
and theSpline
parametrizers internally asm_ts
member variable but don't expose them publicly.Describe the solution you'd like
A way to access
m_ts
, preferably in thetoppra::Parametrizer
interface, so we don't have to worry about which parametrizer is used.Describe alternatives you've considered
We could have a separate class which works out these times and exposes them, but this mapping presumably depends on the parametrizer used.
Additional context
Suggested solution:
parametrizer.hpp
const_accel.hpp
const_accel.cpp
... and the same for
Spline
parametrizer.The text was updated successfully, but these errors were encountered: