Closed matejhof closed 7 years ago
How do we go about this here - @pattacini , @alecive , @towardthesea ? I think it is stable enough and we should merge it to avoid that we have a massive branch with a lot of stuff in it. The basic goal - multiple targets (more precisely - end-eff and elbow) tracking - has been accomplished.
Also, @alecive and his student are planning to use the react-control soon in the Baxter, so it would be nice to consolidate it here I guess.
@pattacini can you perhaps add the tag before the merge in case we ever need to come back to the single-target-master?
Hi @matejhof
@towardthesea is still testing this new branch on the robot. There are conditions that need deeper investigations indeed. Hence, I'd really wait before merging.
The history is not tangled, so there's no risk to mess up.
Ok. Some of the problems under investigation (like IpOpt
exit codes) are may not be specific to this branch though.
Hi,
The testing on robot will mainly focus on considering why the globalTol
has never been satisfied, in the case of reaching a position (with or without planner
). The situation leads to conflict in robot behavior if there is another moving command (through Cartesian Controller
, for example) sent to robot.
Sending stop
command to reactCtrl
can be an option but it is not robust!
I see. Go ahead then!
Merged into master. Main functionality added:
Known issues: disableTorso on
causes segfault
Next: A new devel
branch will be started.
Mainly contains additions that allow additional targets to be specified for react-control. The reformulation is partially generic (for n targets), but in some parts, it is hardcoded only for the elbow. That is
react-control
can accept end-effector only target or end-effector and elbow. The targets can be obtained from rpc (only end-eff) or streamed from supervisor/planner.Contains also corresponding additions for logging and matlab plotting as well as iCubGui visualization.