The output signal from _traj_move may potentially be saw-tooth if it overshoots between points in the trajectory.

We should plot the signal to ensure that this is not the case.

Further, we should investigate mechanisms for interpolating between points to account for this issue.

If a latched pose goal is received before the first joint state message is registered with the robot then the following error is generated

[ERROR] [1636937448.492012]: Exception in your execute callback: matmul: Input operand 1 has a mismatch in its core dimension 0, with gufunc signature (n?,k),(k,m?)->(n?,m?) (size 0 is different from 7) Traceback (most recent call last): File "/opt/ros/noetic/lib/python3/dist-packages/actionlib/simple_action_server.py", line 289, in executeLoop self.execute_callback(goal) File "/home/robot/armer_ws/src/armer/armer/robots/ROSRobot.py", line 372, in pose_cb if self.__traj_move(traj, goal.speed if goal.speed else 0.2): File "/home/robot/armer_ws/src/armer/armer/robots/ROSRobot.py", line 677, in __traj_move current_twist = jacob0 @ current_jv ValueError: matmul: Input operand 1 has a mismatch in its core dimension 0, with gufunc signature (n?,k),(k,m?)->(n?,m?) (size 0 is different from 7)

The current version of the Armer package (stable with rtb 0.11.0-future and swift-sim 0.10.0) has some shake when run on a real Panda arm. Investigation into control code to be tested for review. See work in progress (wip) branch with issue ID for tracking.

When using the following example script the UR5 in the S11 labs reports its end position as x=-0.300 and y=-200 instead of the expected x=0.300 and y=0.200

import rospy
import actionlib
from armer_msgs.msg import MoveToPoseAction, MoveToPoseGoal
from geometry_msgs.msg import PoseStamped
import rospy

rospy.init_node('armer_example', disable_signals=True)
pose_cli = actionlib.SimpleActionClient('/arm/cartesian/pose', MoveToPoseAction)
pose_cli.wait_for_server()

target = PoseStamped()
# target.header.frame_id = 'world'
target.pose.position.x = 0.300
target.pose.position.y = 0.200
target.pose.position.z = 0.290
target.pose.orientation.x = -1.00
target.pose.orientation.y =  0.00
target.pose.orientation.z =  0.00
target.pose.orientation.w =  0.00

goal = MoveToPoseGoal()
goal.pose_stamped=target
pose_cli.send_goal(goal)
pose_cli.wait_for_result()

This was running on a new nuc with a clean installation.

Running the same code in Swift produces a different pose, reverse of the physical pose (as expected):

Armer version: 6b69d0549b8c3123716dcbc6b30c53fe555605e9 armer_ur: 2f67b9d8a60e08ea3e77f7b625546341cc6dbf19 RTB: 0.11.0 Swift: 0.10 SpatialGeometry: 0.2 SpatialMath: 0.11

CTRL-C does not cause nicely quit

(robostackenv) stevem@steveQUT:~/armer_ws$ roslaunch armer armer.launch ... logging to /home/stevem/.ros/log/e526e96c-dfb2-11eb-8d88-b88584a53a39/roslaunch-steveQUT-364430.log Checking log directory for disk usage. This may take a while. Press Ctrl-C to interrupt WARNING: disk usage in log directory [/home/stevem/.ros/log] is over 1GB. It's recommended that you use the 'rosclean' command.

started roslaunch server http://steveQUT:39161/

SUMMARY

PARAMETERS

• /armer/config: /home/stevem/arme...
• /rosdistro: noetic
• /rosversion: 1.15.9

NODES / armer (armer/armer)

ROS_MASTER_URI=http://localhost:11311

process[armer-1]: started with pid [364444] /home/stevem/mambaforge/envs/robostackenv/lib/python3.8/site-packages/swift/out ^C[armer-1] killing on exit ^[[A^C^C^C[armer-1] escalating to SIGTERM [armer-1] escalating to SIGKILL Shutdown errors:

• process[armer-1, pid 364444]: required SIGKILL. May still be running. shutting down processing monitor... ... shutting down processing monitor complete done

https://github.com/qcr/armer/blob/ceeb2dc2b8a20ff88a217d9a4c125a4c195f9a8b/examples/panda_example.py#L12

Hi, the panda example fails because armer_msgs doesn't have all messages and actions defined. Best, Jan

Due to RTB requiring a different version of numpy than is available by default in apt. This causes a version conflict and causes sphinx to not be able to import numpy and generate module docs

This is a two part problem:

1. • Servoing does not incorporate collision avoidance
2. • Trajectory planners in robot toolbox do not currently support collision avoidance.

World configuration files are a must for performing collision avoidance w.r.t. fixed features of the world.

Would be nice if we could import MoveIt workspaces to reduce overhead when swapping.