Week 14: Wildcard Week
This week was wildcard week! I was torn between all the topics (so many interesting ones), but decided to go with Robotic Assembly.
One thing I was considering for a final project was a juggling robot. Claude Shannon created one of the first of these way back at MIT.
Connecting via Python
pipenv --three
pipenv shell
pip install
In trying to find the IP to connect to, I ran in to an issue where the arm info was saying no IP address (0.0.0.0).
I started reading UR10 User manual to see if they document the speed limits and whether 100% is really the maximum speed it can move. If so, a vertical juggle will likely not be possible.
To get IP:
- 169.254.241.97
Characterizing the Movement Speed
We met a couple of times to brainstorm what project we'd want to do, and to split out tasks once we had narrowed in on one.
We thought about a ton of different ideas, from a CNC-controlled Piano player to a CNC Cheese Hot-wire Carver.
Some other robot arm projects
- https://www.youtube.com/watch?v=XTE8xauGTuo - this one is interesting in how it flings with its wrist as well
One interesting thing to note: I was playing with setting the orientation and pose via python, but to start I wanted to check that keeping the same orientation would be a no-op.
robot_start_pose = rob.get_pose()
start_position = robot_start_pose.get_pos().copy()
start_orientation = robot_start_pose.get_orient().copy()
robot_start_pose.set_pos([start_position[0], start_position[1], start_position[2] + 0.12])
robot_start_pose.set_orient([start_orientation[0], start_orientation[1], start_orientation[2]])
print("Orientation:")
print(start_orientation)
rob.set_pose(robot_start_pose, 0.1, 0.1, True, "movel")
robot_start_pose.set_pos(start_position)
rob.set_pose(robot_start_pose, 0.1, 0.1)What I saw, instead, was the rotation changing between each run.
Turned out, I had a mistake, where I was resetting the position in the pose but not the orientation. Adding a call to set_orient in the resetting portion fixed it.
I wanted to confirm the movement distance from python to the
Confirmed that 0.01 is equal to 1 centimeter, so it sets the movement amount in meters.
With that in mind, I decided to target a boundary width of 20 centimeters.
I adjusted the sketch generator's robot arm multiple to be close to 20 centimeters
I hooked up a GUI that would generate a doodle from the latent space of Google's sketch-rnn models.
I made it so it would output the boundaries, and we could control the robot drawing boundaries through a multiple (ideally we could calculate this based on manually set bounds of the robot).
Drawing with a Pen
I started out by bringing down a pencil to try drawing with. As I was gripping the pencil and about to bring it down to zero it on the paper, I realized that a pencil is the worst thing to try to draw with. With enough pressure down, it could snap as it's being dragged.
Then I tried a black sharpie. It worked pretty well, but after a while stopped drawing. It must have started slowly sliding up the grip as it drew. Jake suggested adding a flexure to the gripping mechanism that would allow some give. Another CBA student saw the drawing and suggested I try a marker with a spring-tip.
This worked a lot better. It still had some zeroing trouble. That student also suggested adding a flat surface underneath since the metal board had holes. I tried adding that.
- When the ethernet cable is unplugged and re-plugged in to the same computer, it can no longer communicate with the robot until the arm is restarted (takes a few minutes)
- Squeezing catchup at an angle works better
For more notes on my wildcard week projects, see the Wiki for Robotic Assembly, where there are videos and details on my creations.