Tuesday, September 27, 2016

Robot arm painting

Here's the robot arm at a university run back to school party in the library. The wrist was broken so I just tore it off and put a paintbrush. As usual, I left this for the 30 minutes before the party and the first 30 minutes of the party. No time for fine-tuning settings (counterweight, easel position, angle limits, etc) but it worked alright.

I've done a few of these robot painting things at science fairs. Since this one was for college age students and up, I felt safe handing the controls over. At kids science fairs I can't trust them not to poke out a few eyes, so it can be difficult to get any documentation of the event since I'm always busy with the controller.

Thursday, May 26, 2016

Three wheeled robot simulation

I made a simple simulation to figure out how to orient the wheels of a 3 wheeled robot with independently steering and driving wheels based on a desired instantaneous center of curvature (ICC).  It makes a lot of assumptions (perfect point contacts of the wheels with the ground, no slippage allowed, etc) but is a useful conceptual tool.

Get the latest version here:
https://github.com/eshira/wheelsim (uses Python, numpy, and matplotlib)

The triangle represents the frame. The view is a bird's eye view. Each wheel is mounted on short extensions that pivot about the frame at the vertex of the triangle.  The colored lines are the perpendicular lines to the wheel. Where they meet, a red dot denotes the instantaneous center of curvature, or ICC. The black circle denotes the motion of a point in the middle of the robot.

Below the ICC is at the bottom of the robot frame, marked by the red dot. Points on the robot that fall on the perimeter of the black circle, will move along the black circle if the wheels are driven at the appropriate velocities.

To describe the motion of any particular point on the robot frame, just imagine a circle concentric with the red dot that passes through that point on the frame. The relative linear velocities of the wheels can be described by the relative perimeter lengths of the circles that pass through their center.

Below, we restrict the wheels to only 170 degrees steering rotation (remove 5 degrees from end of range on each side). This creates the red areas, which are places the ICC cannot be without forcing the wheels into the disallowed steering rotations.
The red lines pass through the pivot point of the steering of each wheel. To avoid intersections with the robot frame, and because typical servos only support 180 degrees of rotation anyway, the wheels are mirrored if they pass that boundary. To avoid discontinuous driving caused by having to stop to flip the wheel over to the other side, avoid having the ICC cross this boundary.

Here we have parallel line driving (near vertical direction, along the black line). In this situation, the ICC is very far away. The perimeter of the black circle therefore appears to be completely straight. The wheels are all parallel. The colored lines represent the normals to the wheels, which intersect at the ICC, as they are not quite parallel.

Note that the purple wheel is probably going to collide with the frame if we try to drive straight in the direction of the top tip of the frame. It is probably better to drive as shown below instead.

Above the robot drives along the black line shown, horizontal to the image.

Corrections can be made by turning 'left' and 'right' as shown below.

Tuesday, April 19, 2016

"Pip Girl" (3d printed Fallout 4 Pipboy)

This 3d printed Pip Boy (or Pip Girl) was made for my sister. Her birthday was about half a year ago, and I started this several weeks prior to that event, so this project actually went fairly quickly compared to some other projects on this blog...

The files are from http://ytec3d.com/pip-boy-3000-mark-iv-assembly/

Gluing: superglue, acetone, and hot glue.
Paint: spray paint, clear matte coat, and some touch up with acrylic paints
Modifications from original:
  • Velcro latch (3d printed latch deemed too weak--wouldn't want it to break and fall with a smartphone inside)
  • Did not print transparent PLA light covers (hot glued orange LEDs with orange plastic diffuser in directly instead)
  • White vinyl fake leather cuff with foam padding -- makes it much more comfortable and a much better fit.

Wednesday, March 30, 2016

Patinas and metallic paints

I've been experimenting with metallic paints on 3d printed objects and spray on patinas. Photos and then a description of technique and products below.

My friend purchased some Sculpt Nouveau Metal Coating (Brass, B) that she didn't need, and I applied it to all the pieces above. Tips for using that paint:

  • Sand surfaces with 220 grit if smooth. Surface that are too smooth will be hard, though not impossible, to paint thinly.
  • Brush a layer on as thinly as possibly. The print surface will show through. It will dry fairly quickly. If you can see brush strokes while the paint is wet, that is too thick (unless you like that look). Once dry, if you want to get rid of a brush stroke or drip you'll have to sand it down.
  • Once dry, apply another layer. The deposited metal particles will roughen the surface so that subsequent layers of paint adhere better and get more coverage.
  • The brass paint got brighter as it dried. It sometimes had a dull look when wet but that goes away.
  • The patinas must be applied when the paint is wet to stand a chance of interacting with the metal particles, so apply a final thin wet coat and patina immediately. If too thick, the paint has a tendency to crumble up (cottage cheese is another description I've heard). Some patinas will also just deposit some color on the surface and so would be at least partially effective even on a dry coat of paint.
The patinas I used were the following products from Sculpt Nouveau:
  • Tiffany Green
  • Jade Green
  • Deep Brown
  • Mahogany
  • Vista Rust (Bender head only)
I mixed and matched the for different effects on the different objects above. The Jade Green leaves obvious green deposits immediately on the surface.

Thursday, February 4, 2016

Robot Arm

As part of a mentorship/tutoring thing, I built a robot arm with a student participating in a competition. The design is my own save for the gripper which is modified from this gripper from Thingiverse. This was built mainly during weekends over this January 2016.

The servos are two HS-53 at $8 a pop, a Hitec HS-311 at $8 also, a Tower Pro Metal Gear 995 and a Tower Pro Metal Gear 996 (about $10 each).

The rest is hot glue, wooden poles, zip ties, tape, a paper tower roll, 3D printed brackets. etc. The shoulder bracket was borrowed from a biped robot kit, but could be printed.

The arm is controlled by a smaller model that has potentiometers embedded in it. An Arduino takes care of mapping the values to angle and reflecting it to the servos.

The counterweight is very necessary. This arm reaches nearly 75 cm outstretched. The shoulder (highest up servo) output interface is the biggest ongoing problem. The horn strips out after hard collisions or just slow wear and tear. If the servo output had bigger teeth that would be nice, or if I could find a properly sized hardened steel servo horn that would also help. But all I have is a slightly too big aluminum horn and a set of slightly too small plastic horns. And epoxy, and superglue.

Sunday, January 31, 2016

Battlebots Application

Sector67 submitted an application to Battlebots in December and heard back earlier this week. We were not selected (260 applicants, 56 slots). Here are our videos. I made the renders and bossed people around a lot to get the application out on time (and then became defacto team leader due to that). Credits to Jim for the design, Tim for the proof of concept build and 3d model, Kate for the video editing, and everybody else who was part of the Bad Penny team and help in any regard.

Friday, October 16, 2015

Museum Exhibits Preparation

I'm preparing a robotics exhibit for a local museum that is opening up soon. To that end, I learned how to weld just now (I'm not very good yet. Also now I'll smell like welding all day).

The exhibit is simple--drive a small remote controlled car around a map of the city, from a monitor that tracks the car and displays a birds-eye view camera image, auto-rotated to the car.

The biggest hurdles:
  • Light weight and high capacity battery (but low max discharge rate--which is fine, I don't need a high discharge rate)
  • Sleep mode for the wireless radio and microcontroller to conserve battery when nobody is using the exhibit (chose the Wixel here, for reasons I'll cover in another post)
  • Safety against, stall, over-current, under-voltage, and other battery damaging conditions
  • Making sure the parts the user touches (console, perimeter wall) stand up to the forces users will likely put on these

To adjust thresholds for my wake-up circuit, I finally installed drivers for the portable oscilloscope I have: http://www.gabotronics.com/development-boards/xmega-xprotolab.htm

First impressions: Quick-start was very easy. Installed drivers and software on Windows to get this screenshot, but you don't need to, as the scope has a tiny display.

In the image above I am bringing a flashlight closer and farther from the sensor. The green shows the phototransistor circuit output directly. The red is the output of the comparator circuit (LM358N, CNY70 if you want the parts. Just what I keep in stock, not chosen for any other reason. Don't turn on the CNY70 LED for this application, durr).

I was able to get it to robustly sense when I walked under the fluorescent light fixtures in this building, holding it at chest height.

More on this later.

EDIT: One more fun image.

My fluorescent bulb desk lamp apparently pulses on/off with a cycle taking 7ms or so. The other pattern (where the waveform is getting "pinched" and then expanded) is aliasing from the slow sampling frequency of the oscilloscope (or at least the points drawn in the software) at this large time scale and the 7ms lamp pulse.