Older blog entries for shimniok (starting at number 50)

Robotic Christmas, Autonomous Systems Lab

Here's the 2013 Robotic Christmas video from the Autonomous Systems Lab. Enjoy!


Syndicated 2013-12-17 21:06:00 (Updated 2013-12-17 21:07:21) from Michael Shimniok

10 Dec 2013 (updated 19 Feb 2014 at 01:13 UTC) »

Trash Robot Design, Part 2

Requirements | Design 1 | Design 2 | Chassis ]

Previously we looked at an option of lifting the trash can and driving it down the driveway to the curb. This time around let's look at the other option of grabbing the can's handle and wheeling it to its destination.

Grab the handle and wheel the cans to the curb

The robot can either tilt the can and roll it like I do or drag it flat. Again, one robot. Stock (or slightly modified) can. Less force is required to tilt the can than lift it as you might intuitively guess.

Probably a good idea to do some preliminary calculations on this tilty thing. The force required to tilt the 25kg can around its wheel axles measures 45-50N.

About 45-50N is required to tilt the can at its handle.
If you use some kind of arm to do this tilting, how much torque is needed?
If you use an arm that reaches from the wheel axle to the handle, the distance is approximately 0.8382m from the ground less the 0.0762m wheel radius, or 0.762m, so about 38N-m. If you instead use a shorter arm, less torque will be required of the motor, but you won't be able to tilt the can as far.


Minor problem

While tilting the can, you need to counteract the force required to tilt it. If the chassis has trailing wheels as pictured above, they will tilt up if the force f2 exceeds the gravitational force at the trailing wheels. So to keep the robot from tilting, put a mass over the trailing wheels at least f2/9.81.

There's leverage at play here. If the length of the robot equals the height to the pivot point of the arm, then f= f. If the length is shorter as pictured, then f> f, by a factor equal to the ratio of these two distances, otherwise f< f, by the same factor.

A longer arm means less leverage on the trailing wheels by the arm pivot point. But the motor torque on the arm will have to increase to apply the same force. A bigger motor or lower gearing, meaning lower speed, will be required.

Another option, the robot could drive the motors backwards toward the can while tilting to counteract the force with the main drive motors' torque.

Still another option, put the upright and arm more toward the robot's middle, reducing leverage of the pivot point.

I'm sure you figured out five minutes ago that the simple solution is to put the trailing wheels on the other side, but then one side of your chassis will have to be open which means the chassis will be less rigid unless you add additional reinforcement. Seems like a reasonable solution.

How do you turn?

One more thing to think about when wheeling instead of lifting. How do you turn the robot when you're clamped onto a trash can?

Let's assume the robot will have differential drive because that will provide the best maneuverability in tight quarters the robot is likely to see. To turn the robot, one wheel goes forward, the other in reverse. Each exert an equal force, fw. The total turning force at the robot's track width is 2fw.

The torque exerted by both wheels is 2fwr. Now if you have a trash can with its own wheels sitting on the ground and those wheels aren't coaxial with those of the robot, you have some problems. Here's why (even though you probably know this intuitively).

The drive wheels will exert a force at the trash can wheel. That force will be perpendicular to a line drawn from the can's wheel to the robot's center. How much is the force?


Imagine a there's a virtual arm with a force at a distance r2 shown below. To find the force, take the torque and divide by the arm's distance.

So, for one thing, the force is smaller than it is at the drive wheels. More importantly, the force is trying to move the trash can's wheels mostly sideways. Yeah. Good luck with that.

So either we put our drive wheels next to the can's or we have to have a pivot point where the robot grabs the can.

Pivot Point

With a pivot point we're now able to exert a torque on the trash can. The force at the pivot is still 2fw. The torque exerted on the can is proportional to the radius of this pseudo-trailer's tonque, 2fwrt. The force exerted at the can's wheels is the torque divided by the wheel radius of the can, rc.


If we have a trailer, and we have trailing wheels behind the robot to deal with the lifting torque of tilting the can, that means we have to make the chassis wide enough to let the trash can turn. Something else to think about.

But hey, at least we have a few major design options to try and choose from:

  • lift the can and drive, 
  • drag the can on a pivot, or
  • drag the can with wheels coaxially located. 

There's a lot more design to work out just on the physical side let alone software and electronics. We'll get to all that. But for now, I'd like to start prototyping the chassis. I like to build the electronics once I have some idea of what the chassis is going to look like.

Next: Prototyping the Chassis

Syndicated 2013-12-10 17:00:00 (Updated 2014-02-19 01:04:08) from Michael Shimniok

3 Dec 2013 (updated 19 Feb 2014 at 01:13 UTC) »

Trash Robot Design, Part 1

To be taken out.
Requirements | Design 1 | Design 2 | Chassis ]

My trash robot, TOTT Bot, is going to take the trash to the curb for me. I have a clearer picture of the problem from last time. Time to think about some designs. This is the fun part. Here's what I came up with. Chime in if you have other ideas.
  • Convert the trash cans into robots
  • Put the trash cans on trailer and tow them
  • Lift the trash can and drive it to the curb
  • Grab the handle and wheel the cans to the curb
When one evaluates candidate designs it's best to brainstorm a bunch of ideas and forget about feasibility. Be crazy. Put on the mad inventor hat. You can stodgily evaluate each later, looking for potential issues, and attempt to prune down the list of candidates to explore more fully...

After thinking about zany ideas it's time to be the dark-suit-wearing buzzkill. Frown and look stern. It helps get you in character.

The first two options are out. Why? I don't want to add extra weight to cans that the trash carriers must deal with and I only want one robot.

Let's talk about lifting the can and driving it to the curb first. Some potential difficulties may arise designing for the weight of the cans, their center of mass being so high, the inclined path, among other things.

Lift the trash can and drive it to the curb

Only one robot required. The chassis will have to be able to hold a full 50lbs (20-25kg). And something will have to lift that weight up a short distance off the ground. This might work, but we probably should do some quick calculations.

Drive Motor Torque

So, first of all, how much torque is required to move a 25kg (+5kg robot?) on an inclined driveway? Same answer whether I'm lifting or rolling the can, by the way. And the answer depends on the wheels and gearing and on how much acceleration you want. Actobotics has a 6" heavy duty wheel and a variety of precision gear motors.

You may know that torque is equal to force at a specified distance (wheel radius). And force is equal to mass times acceleration.







I'm using SI units like all the cool kids. Mass is 30kg. Wheel diameter is 0.1524m (6") and the torque acts at the radius. Here's a diagram from Wikipedia showing the forces involved in a free body on an inclined plane.


Gravity, g, is 9.81 m/s2 and the angle is up to 8 degrees. If we were climbing the hill, the geartrain and motor need to generate a force equal to f to stay still (zero acceleration), greater than f to achieve any acceleration uphill, and less than f to accelerate downhill. So how big is f?



We're talking about 41 Newtons (kg-m/s2) to stay still. I have no concept of 41N because I live in America but no matter, let's just figure out motor torque. For a 0.1524m (6") diameter wheel, the torque generated by the motor and geartrain at the wheel radius must exceed 3.12N-m. (If the wheel radius was 1m then the torque required would be 41N-m). It's possible that if the motor is in braking mode, with the torque multiplication of the geartrain it'll be ok. I'll have to verify that later.

Lifting the can

How much force is required to lift the can vertically? The force would have to exceed the can's mass times the acceleration due to gravity, mg or 9.81m/s2 times 25kg which is about 245N. Let's suppose you use a motor or servo with an arm to somehow lift the can. Or a winch with a drum. If the arm/drum has a 0.01m (4") length/radius, the force at that distance is 245N so the motor driving it needs to supply at least 0.01 times that, or 2.45N-m of torque. Two motors halve that requirement. The shorter the arm, the less motor torque required but also the less movement possible.

ServoCity offers a selection of precision gear motors that look like possible candidates for driving such an arm. There are also hi-torque, geared servos available. The 45rpm gear motor supplies a torque of 1.963N-m. Two of them give 3.93N-m which should be adequate for a 0.01m arm. There's also a 20rpm model as well as lower and higher geared models.


ServoCity also offers some killer geared servos. The one pictured above puts out 1281 oz-in of torque when geared 7:1, or over 9N-m. Just one of these servos should be more than enough to lift 50lbs with a 0.01m arm.
Vertical force from rotating arm

Something else to consider is that the torque required is at a minimum when the force is perpendicular to the Earth's surface.

Using a rotating arm, the force will be applied at increasing angles to the force of gravity (see picture). The vertical component will diminish to zero as the arm reaches vertical.

Therefore, it'll be best to operate the arm in a narrow range of angles. Below is a plot of available torque for several motors, given a 0.01m arm, at different angles.

Here's a plot of 0.01m arm angle versus vertical force. The 60rpm motor can operate up to 30 degrees. Any of the lower-geared motors can run up to 45 degrees, no problem.


Ok, that design could work. I still want to double-check the lifting capacity of these motors and servos in the real world in case I goofed up something.

27 Nov 2013 (updated 19 Feb 2014 at 01:13 UTC) »

Robot, take out the trash!

Requirements | Design 1 | Design 2 | Chassis ]

I hate wheeling the trash to the curb on trash day and sometimes I forget. Screw that noise, man. A robot wouldn't mind, wouldn't forget and wouldn't care if it's freezing outside. I'm building Take Out The Trash Robot. TOTT Bot, for short. So there.


A few of the many Actobotics parts I'm evaluating
ServoCity was kind enough to send me a giant box of cool Actobotics parts to evaluate. Seriously. I'm like a kid on Christmas opening the coolest new lego-lincoln-erector-tinker-riviton-toy ever designed!

What the Isaac Asimov is Actobotics, you ask? Lots of cool parts. Precise parts. With drill holes in compatible locations. So, it's easier to prototype. Between the ball bearings, precision shafts and tubing, lightweight aluminum channel, gears, sprockets, chains, belts, and pulleys, not to mention ServoCity motors and giant servos I'm seriously giggling with glee here.

As it turns turns out, I've been wanting to build a trash robot for a few years now. After wondering "what am I going to do with all these parts?" for awhile, I decided the trash robot is the perfect project to see what the Actobotics platform can do for us robot-builders. It's going to take several weeks to build and I'm capturing it all here. Hope you'll tune in while I prototype, build, figure, calculate, screw up, fix, and all that joy. On to the problem statement...

The Problem

When you start any engineering project the goal is solving a problem. So sometimes it helps to actually know what the problem is. Oh, sure, you can run off half-cocked and build something really cool that has nothing to do with your problem. Have fun with that. You'll probably get on Hack-a-Day or something. Me, I like to get a good detailed picture of what, exactly, I'm facing. Crazy, right?

Problem: This. To curb.
I have rolling trash cans (pictured above) that need to get down the inclined driveway to the curb every Tuesday before 7:00AM, or by the same time on Wednesday if Monday was a national holiday. Getting up's easy. Figuring how how to grab this thing with a robot claw ...? Wait, how heavy is it?

Almost 50 lbs. Pretty typical.
When full the cans typically weigh around to 20-25kg (45-55lbs). That's a lot for a robot. No wimpy little robot is going to lift or pull these things around. And sometimes the cans are even heavier.

Size? About 0.41m wide by 0.93m tall (look at me, ma, I'm using SI units). The handle is floppy and is hinged at a height of 0.84m. The cans have 0.15m diameter wheels with a track width of only 0.36m.

Tippy much? Uh yeah. Their center of gravity is always high but varies. If I had a nickle for every time these stupid things fell over, spewing trash all over, while I'm dragging them to the curb in my jammies...  Well, that's some fun stuff right there.

Floppy handle hinges at a height of 33"

Angle finder shows about 6 degrees, steeper elsewhere
The driveway is inclined 6-8 degrees and the shortest distance from garage to curb is approximately 9m but the path isn't a straight shot. That's because normally my lifted, rusty, trail-prepped, rock-battered 1986 Jeep Grand Wagoneer is prettying up the driveway on the left. I don't know where I was when Google took this StreetView picture, odd... The robot will have to go around the big ugly truck. Without showing fear. The truck can smell fear.

My humble abode. Note trash cans and missing Jeep.
My wife's car is in the garage on the right when the trash needs to be taken out. To the left of the driveway are rocks. The trash cans are typically located where you see them in the picture. Eventually I'll relocate them inside the garage.

When the trash is picked up the trash collector lifts up the can and dumps it into the truck, then runs the cans back up to the garage where you see the cans pictured above. (It's a neat little value-add)

I should mention, too, that I only want to build one robot to carry cans one at a time, not some trash carrying swarm.

Alright, so that's the problem in a nutshell. Ok, sure, there's more details to gather, but good enough for now until I consider some possible designs for this trash robot.

Oh man, this is going to be great! No more trash carrying! Yes! I invite you to join in, follow along, subscribe, share, all that stuff.

Next Time: Evaluating Candidate Designs

Syndicated 2013-11-27 17:00:00 (Updated 2014-02-19 01:00:29) from Michael Shimniok

26 Nov 2013 (updated 27 Nov 2013 at 20:09 UTC) »

Pololu Black Friday

Pololu is doing another Black Friday sale this year! Lots of great deals. (No affiliation, I just like Pololu). (Update: click here for deals from Sparkfun, GHI, Parallax and Bot Thoughts!)

 

Pololu Robotics and Electronics is having its biggest Black Friday sale yet, discounting hundreds of sensors, actuators, motor controllers, and other robot parts by 30% to 60% and offering an additional 11% to 15% off orders over $100! Buy one Zumo Robot and get one free, save on a 3pi Robot and get a free programmer, and take advantage of great deals on select Arduinos, Raspberry Pis, and mbeds. The first doorbuster deals go live Wednesday, November 27, and the sale runs through Cyber Monday (December 2). For details, visit www.pololu.com/blackfriday.

Syndicated 2013-11-26 15:00:00 (Updated 2013-11-27 19:20:30) from Michael Shimniok

Cyber Monday, New Products!

Announcing Bot Thoughts Cyber Monday discounts! Details here.

Syndicated 2013-11-25 06:59:00 from Michael Shimniok

Microchip PIC 24F, 10MSPS 16-bit ADC, 2x OPAMP, DAC

16-bit, 10 MSPS ADC, dual op amps and 2x10bit 1 MSPS DAC. In case you were wondering MSPS is Million Samples Per Second.

If you're not picking your jaw up off the floor then maybe some comparisons will help.

AVRs have 10-bit, 15 kSPS ADCs. That's kilo-Samples Per Second. Two orders of magnitude difference. The ARM NXP LPC1768 can do 10-bit conversions at 500kSPS. There are Kinetis ARMs that do over 800kSPS. The dsPIC33F has 10-bit, 1.1 MSPS converters which used to be impressive to me.

Oh, and 10 bits is ok, 12 bits is pretty good. But 16 bits is crazy resolution for an MCU. Usually more bits means slower sample rates. And yet...


10 MSPS is a quantum leap. That's some rarefied air in that realm. Usually only specialty ADC chips run in the 10MSPS range. And they have to have parallel interfaces to pump data that fast. Then to throw dual op amps and dual 10bit 1MSPS DACs in the mix?

Holy analog ass-kicking, Batman.

Yeah, that's cool. It's a new PIC family: PIC24F including PIC24FJ128GC010, PIC24FJ64GC010 (BGA, 100-TQFP), PIC24FJ128GC006, and PIC24FJ64GC006 (64-TQFP and QFN).

Microchip Technology Inc. announced a new family of microcontrollers (MCUs) —the PIC24FJ128GC010. This family is an analog system on a chip that integrates a full analog signal chain, including Microchip’s first ever on-chip precision 16-bit ADC and 10 Msps 12-bit ADC, plus a DAC and dual operational amplifiers (op amps), along with extreme Low Power (XLP) technology for extended battery life in portable medical and industrial applications.
Here is the original article. So, I would imagine you could build a pretty awesome, cheap, portable oscilloscope, logic analyzer, spectrum analyzer, audio recorder, portable MP3 player, ... etc. Dang.

Should I design and sell a breakout board for this bad boy? :)


Syndicated 2013-11-21 17:00:00 (Updated 2013-11-21 17:00:01) from Michael Shimniok

Hacking a dual rail supply for HP204 oscillator


I built a custom power supply for my HP204 oscillator and cleanly modded screwed up, hacked things together, and eventually shoehorned it into the case.

Now why would I go and do all that? Read on...

I hacked my HP204D, similar to the HP204C, because the waveform sucked at low frequency settings. Mine was battery operated but the batteries were missing. The power supply circuit was designed to charge those long-gone batteries and, without them, it doesn't supply the correct +13V and -13V voltages.

I originally planned to make use of the original diode bridge rectifier and be all clever. I was going to cleanly replace the original transformer with a new, center-tapped one that I'd been saving for just such an occasion. Pretty much none of this worked out.

The transformer output a rather high voltage requiring large, high cost capacitors that wouldn't fit in the case. I discovered this after I cut holes for the big transformer. Oops. I bought a lower voltage transformer and selected cheaper, smaller, shorter input ripple filtering capacitors.

The new transformer was a bit smaller than the old so the hole I'd already cut into the circuit board was too big. The install wasn't quite as clean as I'd originally intended. It's good enough, though. The transformer is affixed to a single, existing mounting standoff affixed to the PCB by the factory.

Smaller transformer, back panel, prototyping regulator
As for the original bridge rectifier, I goofed up and blew out one of the diodes, then trying to repair that, I damaged the traces, lifting them off the PCB. It was time to give up on that plan.

Some day I may build adjustable positive and negative power supplies with LM317/337 ICs but as an interim fix, I went with +12V/-12V design using 7812 and 7912 regulators.

Simple home-etched +12V/-12V supply
After breadboard prototyping, I designed the circuit and layout, etched the board, removed all the original regulator components and tapped into existing +V and -V traces so I didn't have to change the green card edge connector, too.

Regulator with soft start resistors
Then I shoehorned the supply into place on the internal frame out of the way of other components. The transformer is wired from the mains socket through a switch for 120V/220V compatibility. I don't know why I retained that feature since I have no intentions of taking this device overseas. Whatever.

Regulator tucked in on the internal frame.
The custom board features a compact, 400V bridge rectifier, 1000uF ripple capacitors, 1.5A 7812/7912 regulators, and 100uF output capacitors. As a final step, I installed a fuse on the AC hot side.

Sparkfun AVC 2014 Announced

Sparkfun has announced the date and venue for the 2014 Autonomous Vehicle Competition. June 21st at the Boulder Reservoir. Details here.


Syndicated 2013-11-18 16:49:00 (Updated 2013-11-18 16:49:08) from Michael Shimniok

ATtiny Software Serial

ATtiny software serial transmit and receive, based the Arduino SoftwareSerial library, and around 1K compiled. That's what I've been working on. Why?

Spy photo :) of ultra compact eeZeeISP AVR programmer
I'm designing a low cost, really small AVR Programmer, that's why. It's based on an ATtiny84A and requires SPI which claims the USI peripheral, leaving no hardware serial.

Here are the details on TinySoftSerial.

Overview

The current Arduino
SoftwareSerial library is based on the NewSoftSerial library by Mikal Hart. A few years ago, NewSoftSerial was a dramatic improvement over then-incumbent SoftwareSerial, which is why the new code is part of the Arduino 1.0.x distribution.

Multiple serial listeners are supported at baud rates from 300 to 115200 though errors above 38400 at 16MHz may be too high and lower rates too slow. Overall, it's a really neat library for typical communications of 9600 - 38400.

So you may see why, when I needed serial receive (the hard part), I didn't really feel like reinventing the wheel. I need the library for other projects, too. But I needed something small and with only one software serial instance.

What I Did

  • Converted to C
  • Removed multiple instance capability
  • Converted to native PORTx/PINx/DDRx register references
  • Hardcoded to use PA0 for RX and PA1 for TX
  • Shaved a few bytes here and there,
    • e.g., using a mask instead of modulo for circular buffer**
  • Adapted interrupt register references to ATTiny84A: GIMSK, PCMSK0
  • Hardcoded 16MHz timings (for now; I may restore the other frequencies later)
  • Fixed "Error: register r24, r26, r28 or r30 required" - details
  • A few other things I can't remember
The result is pretty small. The following is for the library with a simple main() that echoes characters you type:

  avr-size --format=berkeley -t TinySoftSerial.elf
   text    data     bss     dec     hex filename
   1008       2     204    1214     4be TinySoftSerial.elf
   1008       2     204    1214     4be (TOTALS)
Finished building: sizedummy

** If you're curious about using a mask instead of modulo. Let's say you have a buffer of 64 bytes (or any number 2n), aka 0x40 or 26. Indexes range from 0x00 to 0x3f or 000000 to 111111. After you increment your index, simply AND it with 0x3f (2n-1). Suppose the index is 0x3f, the maximum and you increment it to 0x40. Now AND with 0x3f and you get 0x00  (%01000000 & 111111) . This is faster and uses fewer assembly instructions to implement than modulo or an if statement. Here's what it looks like in C:

#define MAXBUF 64
#define BUFMASK (MAXBUF-1)
...
char buf[MAXBUF];
...
i = (i+1) & BUFMASK;

The Code

I bet you just want the code. Ok, here it is.

Source Code

Porting to ATtiny85, Etc.

It shouldn't be too hard to port this to ATtiny85. You could port to ATtiny2313 although it has hardware serial separate from the USI. The library is too big for ATtiny13 to do anything useful. I don't use any other ATtinys but basically anything that has 2K flash or higher should be a go.

Saleae Logic Analyzer: STK500 V2 protocol

Syndicated 2013-11-14 17:00:00 (Updated 2013-11-14 19:42:47) from Michael Shimniok

41 older entries...