Everett Yang
I am a rising senior CS major from Texas A&M University working in Nancy Amato's robot motion planning lab.
Week 1
This week was mainly about setting up the computers
James and I brought from A&M and
settling into the new lab
and the new town.
We had Glen help us
with installing the dependencies
and connecting the computers to the Illinois server.
I read (and am reading) some papers related to
manipulator planning under constraints to try
to achieve a deeper understanding of the problem.
Specifically, I've been looking for
past algorithms that provide a general solution
to this problem.
Here are a list of papers I am reading:
1. Manipulation Planning with Probabilistic Roadmaps by Simeon et al.
2. Trajectory Planning for Manipulators Operating in Confined Workspaces by Kabir et al.
3. A constraint-based method for solving
sequential manipulation planning problems by Lozano-Perez et al.
The first one of the list is particularly interesting and helpful because they
provide a clear definition of the constraint problem and
a general solution to it. I plan to read the details later.
I spent a good chunk of Thursday
and Friday getting PMPL set up and helping
other students. I ran into some annoying
bugs that Diane helped me with.
We had a group meeting for the first lesson
of the crash course on Friday. Diane did a good job
explaining all of the basic concepts.
I plan to turn my thesis work into a publishable paper.
I will collect more data and present a more solid
contribution (the contribution is a bit shaky right now).
In addition,
I will try to brainstorm some original ideas
for constrained manipulator planning in general.
Week 2:
I had a report here now its gone.
Week 3:
I'm trying to implement a fixed based multi-armed example to demonstrate my reachable volume algorithm. I'm having trouble figuring out how to deal with two different manipulators in the same problem. I need to be able to compute their reachable volume intersection so that I can figure out if one context has a transition point with another, but I can't seem to find the right tools in PMPL to do so. The most relevant thing I can find is the GroupCfg framework. But that also isn't exactly what I want because I don't want to calculate the reachable volume of the system, just each individual arm.
Hopefully I can figure something out next week.
I'll send a more detailed plan for the paper tomorrow.
I also have some skeleton code for the RV local planner set up. So I will also work on finishing that next week.
I helped Felipe with his discrete environment strategy. I suggested a way for him to build some contrived graph and also helped him manually choose his start and goal from the same graph after it is built. It didn't take so long because everything was essentially hard-coded (which isn't ideal but he insisted that is what he needed).
The lab went out to Joe's on Thursday for burgers and a couple games of bean bags. It was fun.
Week 4:
made progress in the RV stepping and local planning code this week. I have a base
implementation for the local planner
and the stepping function that compiles.
However, there are a few things
left to figure out
in order for the local planner
implementation to work:
1. Implement a function to check
whether a point is inside a RV intersection
(for RV stepping). Right now we only have a
function for randomly
generating a point in the intersection.
2. Generalize the above to handle arbitrary
number of intersections. (This is probably not
an immediate concern).
3. Make sure the "parent" chains are
what I think they are in the literature.
Right now I am just breaking the
big chain into two smaller chains
that meet at the joint to be stepped.
Not sure if this is correct. This also
affects the "neighboring" joint calculation.
Also, I am making a few functions in the ReachableVolumeSampler static in order to reuse the code in the planner.
Not sure if this is ideal.
After I get the local planner working
(presumably next week if all goes well), I
will run some pick and place examples,
first with the simple manipulator
then hopefully with the Kuka.
I am thinking of running such examples
by:
1. Giving two end effector constraints
2. Sampling nodes that satisfy these two
constraints.
3. Use the local planner to incrementally step
nodes from the first constraint (pick up point) in the list to the second constraint (drop off point).
A concern of mine is that
I am not quite sure how far we
should go for the ICRA paper. I was
thinking that the algorithm should be
general enough to automatically detect transitions between
contexts (and so this could be the
proposed novelty),
but it seems this isn't really needed
since the constraints and their ordering
in the problem are both given in many scenarios.
Then I am left to think that
we need only more examples
(specifically ones with end effector
constraints)
on top of the one in my thesis
and that the novelty is in
the way we sample from the
set of given ordered constraints
(done in my thesis).
I continued to help Felipe with whatever
questions he had this week.
It seems he is more comfortable with the
library now.
It seems I will be presenting my
research at MAA MathFest
this year once again.
Like last year, the math department
and MAA is covering all the costs and
perhaps even more.
The conference is in Cincinnati this
year, so pretty close. There are a few others
from TAMU going as well.