Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create a generator-enabled trajectory #168

Closed
jgvictores opened this issue Dec 13, 2018 · 4 comments
Closed

Create a generator-enabled trajectory #168

jgvictores opened this issue Dec 13, 2018 · 4 comments
Labels
priority: idea super cool Unicorns can write code, too wontfix

Comments

@jgvictores
Copy link
Member

jgvictores commented Dec 13, 2018

Create a generator-enabled trajectory.

I've become very fond of the generator design pattern, and I think it makes sense in at least 2 scenarios we are going to find:

  • Offline generated trajectories that can be "theoretically infinite", such as following a straight line, or pre-programmed pendulum movements or walking gaits.
  • Online generated trajectories.

Extra points if the generator is wrapped and can be programmed outside of C++, aka Python!

PS: This idea is in line with #135, oriented at designing and running more complex trajectories, so blocked by #134 as well.

@jgvictores jgvictores added blocked Do not focus on this issue until blocking issue is closed priority: idea labels Dec 13, 2018
@jgvictores
Copy link
Member Author

By the way, still not sure if a new class, or reusing an old class and setting duration to a reserved negative number, etc.

@PeterBowman
Copy link
Member

Offline generated trajectories that can be "theoretically infinite", such as following a straight line, or pre-programmed pendulum movements or walking gaits.

Following a straight line (at constant speed) is implemented in movv: #170.

Online generated trajectories.

And this one should be achieved with plain movi.

By the way, still not sure if a new class, or reusing an old class and setting duration to a reserved negative number, etc.

Idea: don't over-complicate BasicCartesianControl and prefer external trajectory generators. I would wrap my generator routine in a yarp::os::PeriodicThread/yarp::os::Timer and make it speak to the cartesian controller via CartesianControlClient.

@jgvictores
Copy link
Member Author

When I opened this issue, it was an idea inspired by the generator pattern I saw in Python, as I believed there could be some easy and portable similar mechanism in C++. It turns out that SO points out some (imho) pretty convoluted implementations (ref).

Maybe some day C++ will support Python-style generators with a proper yield keyword and a next member. This assumption may not be so far-fetched, e.g. ES6 Javascript adopted a similar mechanism (https://codeburst.io/understanding-generators-in-es6-javascript-with-examples-6728834016d5), but I'm not sure we are anywhere near that day in the C++ development roadmap.

TLDR: How about closing this issue as a wontfix, and instead focus on the mini-"infrastructure" with examples of working code such as the yarp::os::PeriodicThread/yarp::os::Timer mechanism you mention?

@PeterBowman
Copy link
Member

I agree that iterators are (and have always been) the C++-ish way to go, at least for now. I am not sure though about the scope of this issue. Where and how is this hypothetical generator supposed to fit? I'm not convinced to have it embedded in BasicCartesianControl since it would probably require another rework on the ICartesianControl interface. As I see it, such more advanced trajectory generation techniques are better placed outside the controller (separation of concerns), be it C++ or Python code. In that case, you can trick KDL motion API into generating endless trajectories: #134 (comment). More complex stuff involves resorting to for loops, as usual.

In other words, I think you can already have "generation-enabled" trajectories today.

TLDR: How about closing this issue as a wontfix

Since you agree, I'm proceeding to do so. Please feel free to re-open and/or provide further details on your proposal.

PS see exampleScrewTheoryTrajectory regarding the implementation of a basic PeriodicThread mechanism.

@PeterBowman PeterBowman removed the blocked Do not focus on this issue until blocking issue is closed label Mar 17, 2021
@PeterBowman PeterBowman closed this as not planned Won't fix, can't repro, duplicate, stale May 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority: idea super cool Unicorns can write code, too wontfix
Projects
None yet
Development

No branches or pull requests

2 participants