Showing posts with label design. Show all posts
Showing posts with label design. Show all posts

Wednesday, February 4, 2015

Rethinking project directions (a long post)

So I've recently focused on using the "130 size" motors that are widely available to power my robots.



I ran into one major issue today though. With the robot fully loaded (I put a pretty hefty battery on it, about 115 grams) the load was excessive, and within 1-2 minutes of use the motor overheated. As it overheated, the robot began to slow down. Eventually, the motor shorted. When it did the motor driver was zapped. In this particular instance, the motor driver then shorted the motor voltage line to the Wixel, which zapped the Wixel too. The magic smoke was released, and the electronics were no more. How disappointing.

My robots were operating at the "Heavy Load" region; bad news


Mostly though I was bummed out to find that I need to do a lot of redesign, ASAP. Pride can get in the way here, and I'm conscious of that. Just because I sank a lot of time into a design, doesn't mean I should be hell-bent on polishing it until it more or less functions. Perhaps it is time to take things in another direction, as frustrating as that is to admit.

So, I did a little more late night reading. I started by returning to this video, which shows a robot that appears to be made with CD drive motors, belt drive, bottlecap wheels, and a bead caster. It is zippy, seems to feature some kind of lightweight battery, and it seems 'low cost.'



However, I can't seem to find cheap brushed CD motors in bulk. The salvage on eBay is surprisingly expensive, and also not always sold in uniform lots. The process of salvaging is time consuming and parts may not be available to all.

Below is a motor/wheel/gearbox that is probably a really good option. It seems to use the 130 size motor or something similar, though I haven't gotten a sample set of these yet. At $3.xx if you buy them in groups of at least 2 (that includes ePacket shipping; these mostly ship from China), that isn't a bad deal. Ultimately given the time and plastic costs with 3d printing wheels and gearboxes, I think I should have been trying these out.




I think perhaps I had a bit of confusion as the MOARbots mission evolved. In the beginning, I was really keen on using some of my collection of motors, many of them salvage. Over time I realized that I specifically wanted to avoid salvage for reproducibility reasons. Part of that was reading over so many unhelpful and poorly written Instructables...



Pictured above is SWARMbot from AFRON 2012. It uses some very small motors hooked up to bottle caps with direct drive, and runs on a single LiPo cell. Direct drive is something I found really tricky with bots on a larger scale, and I wonder how much weight you can put on this thing before it stalls. Depending on your needs, that may or may not be a problem.



This was the other intriguing design from AFRON 2012, the LollyBot. I mostly liked the style of drive with the rubber tire friction. I was pretty surprised to see the price on the cheap dual stick controller listed as about $3.80...the link didn't work for me, so I don't quite believe that price yet...

At this point I was feeling a little bad, so I decided to remind myself of what MOARbots is still important for. Here's a list:

1. A collection of modules, resources, and general knowledge instead of a single model of robot.
Up to now I've still had trouble finding information about what to buy, where to buy, design considerations, how to pick and choose, etc. Even with some of the excellent designs above, they provide just instructions on how to build their design. One of the goals of MOARbots is to generate a big, easy to navigate set of resources that help you understand how to successfully pick and choose design elements. I'm learning a lot in this process that I want to share, but I don't think a big rambling article is the way to share it. I need to think of a good format.

2. Digital wireless while maintaining low cost / Code
The Arduino is very popular, but adding it with some wireless module costs more money. Because the Wixel was actually a little cheaper and included a wireless radio, I decided to go with that. The Wixel community is a whole lot smaller than the Arduino community and it shows. Hopefully part of what this project will do is contribute to that community the sorts of resources that people doing robotics projects similar to MOARbots will need. What is needed? Mostly glue between existing code modules that others have written, instructions to make use easier.

Of course, if I can find the time, I'd like to also start trying to switch the Wixel out for the ESP8266 instead. as I've mentioned before. Pointing people toward/providing a tutorial for getting started with AprilTags could also be a goal. By using something and inviting others to follow you add to a community, and then the community turns around and contributes back things you find useful, most importantly perhaps being posts on the internet about solutions to problems.

3. Cheap omniwheels
I left my omniwheel project alone a while back to focus on the other aspects of MOARbots, but as far as I can tell cheap 3d printed omniwheel designs still aren't really available online. Of course by the time I have a chance to finish mine, I'll find out somebody else finished it for me. But you saw it here first folks! 3D printed plastic plus finishing nails and rubbery heat shrink. That is probably my most original mechanical design contribution. My omniwheel design.

4. Alternatives/Redundancy/Options
I think it is better to have more options than just one. Users will surprise you, and you can't really predict the things an arbitrary person searching the internet for low cost DIY robots will need out of a framework/platform. Having a lot of alternatives is a good thing.


Wrap-up: what's next? Well, the most pressing issue for me is to fix my fleet of 10 robots with overheating motor issues. I'd like to use the same parts because they have already been purchased, so I'm not switching now to a design that is too drastically different.

One final thought: I want to reiterate how important it is to have a central knowledge base that is easily navigable. I keep finding gems hidden in obscure forums online. From the link describing this video, this description : "Its a belt drive car. Used a bobbin from a sewing machine on the axle and used a bicycle tube cutout as the belt. This is working for now, but I need to find something a bit better as the connection between the motor and the axle is too loose." 

I wish the internet had a good user uploaded content driven website focused on listing 'household' items tagged with different uses for them. Then you could see more by following links to builds and writeups. You could also watch prices and find sources for buying in different quantities.

Last edit: two links I wish I had read in detail earlier on:
http://www.phidgets.com/docs/DC_Motor_and_Controller_Primer
http://lancet.mit.edu/motors/motors3.html

Sunday, October 26, 2014

Omni Wheel Prototype

There was a plan this week to give a very small talk about my robot to a very small group of people. Then it grew into a much bigger event--university departmental computer science talk. Suffice to say, now I'm pretty amped up as well as reasonably nervous.

All this required me to think very hard about what I've been doing, what sets it apart, why it is useful, and to whom. And one thing that came out of that was me realizing that some omnidirectional wheels need to be part of my framework because some users in my talk audience will need them. Existing omnidirectional wheel designs on the web didn't fit my design principles and needs very well. So I designed the one below.

With beads assembled

Frame only

The key things about this design are as follows:
  • It only requires one piece of hardware--some wire. I have some 16 or so gauge steel wire, but you can pick anything that feels right to you for your size of wheel, and input those dimensions into the OpenSCAD file.
  • Everything can be changed easily in the OpenSCAD file. Number of beads, shape and size of the bead, gauge of the wire, etc. This will be more true after some cleanup on my part, when I get it ready for release on Thingiverse and elsewhere.
  • Everything besides the steel wire is 3d printed. It is often easier to 3d print beads than to find beads that fit the wire closely.
  • The 3d print does not have to be split in two in order to print. Assembly is simple and doesn't require any 'finicky steps.'
    • This is because the channel for the wire is opened up, specifically at the point where printing more of the channel would break the 45 degree rule of thumb for 3d printing. It has a snap-in kind of feel.
    • Hot glue can be used optionally to help tack down the wire where needed.
    • The wheel hub/gear module will be added on top in the final version without any fuss. To illustrate how this can be a problem with other designs, consider the version where an enclosed channel is created by printing the wheel in halves split along the central X-Y plane of the wheel. In order to not break the 45 degree rule, you have to print the inside faces up. In order to print the wheel hub though, you need at least one outside face up. (My solution in that case would have been a triangular channel).
I'd like to come up with a few more variations on this, and maybe tackle a similarly informed design for Mecanum wheels or two-layered omni wheels.


Here's a first 3d print. The beads will be spray coated with Flexible Rubber, a product sold mostly for sealing up cars and boats. They'll be loaded on a skewer and finished in bulk, which is an important point when you have this many parts to finish. This will also make it more feasible for me to spend the time to apply multiple layers, to get a good thick rubber tire on each.




Looking good--only minor design changes and a little finishing work is needed for this particular mix of the OpenSCAD parameters to be more than a demonstration prototype.

Oh, and I should mention: this wheel cost about 63 cents! That's 60 cents of 3d printed plastic and a few cents worth of steel wire. The wheel is 6cm in diameter.

Friday, May 9, 2014

Evil Product Design

This post will serve as the Hall of Infamy for product design. I'll update it as I find more examples. I don't own every product listed here, so some of my info just comes from product reviews and stories I find online. I actually put that line there because in light of the recent scandal where Mediabridge/Medialink lost their Amazon seller privileges harassing a critical reviewer, I don't want there a company threatening me for holding one of their products in poor esteem. These are just my opinions and my data might not be completely accurate!
  • An Optrel welding hood with planned obsolescence in the form of some 'non-serviceable' coin cell batteries encased in foam.
  • Dropcam is a surveillance camera that won't let you record locally. The hardware is $150 but you still have to pay $99 to $299 to use it with their cloud service. Here is a critical review from somebody who unwittingly bought the thing. It seems pretty obvious that they don't want you to use your own solutions for what to do with the video stream.
  • The general concept of selling one piece of hardware with different firmware installations at different prices. For example, oscilloscopes. If you could afford to sell me the hardware at that price, then you could afford to sell it with non-throttling firmware.
  • Back in the day when webcams were first getting popular and Apple was still trying to pit FireWire up against USB, my dad bought a USB webcam that was advertised as compatible with Mac. It was...but only if you forked over additional cash for the drivers by the same company that sold the webcam. There weren't generic drivers at the time, or at least most customers didn't know about them.
  • I went to a talk where the local fire station demo'd their equipment and it was really cool, but they dropped a mention of a yearly licensing agreement that they have to pay for the software and possibly firmware that go with the device. I was really confused and didn't get a chance to ask more questions, but I feel like something is amiss here. This equipment is specialty stuff, meant to work in extreme heat and with low failure rates (or certainly I should hope so!), and it is probably very expensive already. Nickle and diming the taxpayers for some of the simplest software and firmware out there (all it does is tell you how strong the strength is from the wireless pinger on the firefighter suit to the magic wand)? I wish I could be more angry at the company but some of that anger has to be directed at the (faulty) system by which our government chooses contractors and suppliers of equipment.

More to come.

Sunday, April 27, 2014

Tessellating Scales Design

I finally bought some food-grade pourable silicone for some of my projects. In the next few weeks I'll hopefully be milling, prepping, and pouring my designs.

Below is a tessellating scales design I put together. It will become a mold for making chocolate bars. The scales can be individually filled with colored candy melts and then the chocolate will be poured to fill the rest of the mold and create the bar. To streamline the multi-color candy melt pour, I think I will use these silicone squeeze tubes, keeping them warm in a warm water bath.

The design is available here as a pdf.