A new project.


My son took immediate notice of this month's Nuts&Volts cover. Displayed are 3 LED lit name plates ... one being EVAN. "Daddy will you make Evan for me". I jumped at the chance/reason to get my CNC up and running. So I spent Saturday learning/re-learning how to use CAM, Mach3, and my CNC mini-mill.

I used a bamboo organizer box as the base/case and a piece of PVC for the top (that stuff is too useful IMHO). I am using 6 blue LEDS running off a 5 V 270mAh receiver pack (from my RC stash) drawing 20mA.

Of course this is just the beginning, he already want version 2 with blinking/fading lights and knobs and switches.

Edit, not too long after I decided to make some signs for a buddy's little girls. Rather than mill through, I back engraved the acrylic for a nice effect.

Jay

Something new:

I leaned something new the other day and decided to give it a go. Charlieplexing is a type of multiplexing for LEDs that allows N pins to control N*(N-1) LEDs. So 5 pins on a Tiny13 can control 20Leds. I used 14 and here is the result:

Update: I tried POV (persistence of vision) but I'm not really clear on what needs to happen for the affect to show up. It was a half-hearted attempt to say the least.

Jay

Gripper: final version with new video and source code

As promised here is the source code. Also, I hinted at another project I want to tackle .. .that being an electromagnetic levitator. I think the Tiny is up to the task :)

Of course it would behoove me to get my development environment built too. I programmed the Tiny at least 50 times, by removing it from the socket on my circuit. I need to order a ZIF socket, a 6-pin programming cable, and a longer USB cable so I can do ISP and debug wire on future circuits :)

Jay

Updates: 3/12/2008:

First let me say that if you are an engineer and a father a great "toy" for both you and your kid(s) is the Snap Circuits kits from www.elenco.com (available at Radio Shack for a premium price). We bought the Jr. kit as my son is only 4 and he and I have already made all 101 circuits in one day. I have since ordered the Extreme kit which should offer all kinds of experiments. it just arrived today :D I recommend you get the Extreme first.

Now back to my gripper controller project. I have decided to continue improving the design some more. Most all my friends that have seen the video have commented that the motion looks too jerky and that it's not obvious that my hand is controlling the position of the servo. To address these I am going to modify the code to only update the servo position at 5Hz even though the A2D is being read at 20Hz. Furthermore, the servo position will only move +- 1 each iteration. I may change this based on the actual movement I see of course. As for the second issue, I'll just shoot a better video and maybe add some explaining :) I also plan to add in another sensor to control the gripper opening and closing the same way.

Forward,
Jay

Update 3/10/2008:

I been MIA working on some paying projects. After I completed that, I got drawn into a new venture with a buddy. I can't say too much about what it'll be, but in order to get ready for it I've been playing with a new chip (to me anyway). The Atmel Tiny13.

Pros:

• 8-pin dip $1.29
• No xtal needed has internal clocks up to 9.6MHz
  
• Supports in-circuit programming
• 1K flash, .5k EEPROM
• 6 I/O all of which can be digital or 10-bit A2D
• Requires a pull-up on reset
• Uses the same GCC compiler as I am used to

Cons:

• Internal clocks while they can be calibrated are somewhat inaccurate (thought they work fine for what I want)
• 1K of flash goes fast :)

In a nutshell I wanted a servo tester/driver. So I surfed the web, found snippets of code here and there, and came up with a little demo. If I were to use this on my robot, I would change it to trigger a "pickup" sequence of servo moves. However, I've never really played with the A2D on an Atmel and I purchased 4 Sharp gp2d12's so I figured why not. The A2D is read about 40Hz which is also how often the servos get a new value (if required). The timer ISR is set to execute every 13us. At the end of every 20ms frame, the servo signals are turned on. Each run of the 13us timer subtracts 1 from the servo count until it reaches 0. Then the servo pin is turned off. I'm only using the upper 8-bits of the A2D conversion (16-bits adds a lot to the program size and I don't think it's needed). The most current reading is compared to the previous reading + or - 7. This is to prevent the servo from "jerking" all over the place, but it results in visible "stops" in the video.

Here is a video of the results. I may add to it, I may not. The important thing is that on a 1" square PCB I can have a multi servo controller that uses analog feedback to position the servos.

I promise to post the source code once I get it cleaned up (this was just quick and dirty) and commented.

Forward,
Jay

Progress 1/21/2008

While I should be working on a different project I worked on my robotic gripper design today. I have posted video of prototypes 2 and 3.





Jay

I'm still here, just recovering from the Holidays. My plans to use an RTOS have proved to be too much work and not enough progress so I am going back to my interactive code. At this point my robot is still and R&D tool for me to test my code for a specific purpose so I don't actually need concurrent threads of behaviors.

My next little project is to code to control my 2-DOF gripper. What's that you say, you didn't see any posts about my updated gripper. I'll post some photos soon. The code shouldn't be difficult using the AVRLib library though.

Jay

One step forward, two steps back:

Well I shot myself in the foot so to speak. I took my code to work to hammer out some of the details. This meant a lot of changes without being able to test them. Somehow I incorporated old code into the new code and contaminated both :(

Long story short, I'm going back to a reliable backup on 11/25/2007 which was before my last two posts. Thus, I'm progressing in the wrong direction. The good news it, I'm incorporating the code optimizations I made recently into the old code prior to me breaking out the functions into their own files. This way I can know they work before I change too many things at once.

On a good note, I've been mocking up a claw mechanism at lunch today. Saw a YouTube video of one I liked and fashioned a working model out of craft sticks.

Jay

Updates 11/28/2007:

I have successfully added RTOS (real time operating system) to my code. I'm using FreeRTOS (www.freertos.org) and it was relatively painless to incorporate. Some of the details that slowed me down:

• The kernel timer uses Output Compare 1A which is the same I was using for the right motor PWM.
• The port.c file configures the Timer 1 only for Output Compare 1A which overwrites all my settings for pwm I set in my motorInit code. As such, I changed the code in port.c to use |= when setting it's bits. This is the only kernel change I had to make.
• I used to have all my code in one file. This is due to the fact that I just kept adding on to experimental code rather than formalize everything. Prior to the addition of the RTOS, I broke out functions in to separate files based on organization (motors, motion, and eventually sensors).
  
• I was also using a lot of global variables (bad form I know but it's been fixed) in my one file. Rather than declare them extern in my new files (yes I tried that at first), I added functions to "get" and "set" key variables.
  

The benefits of this rework?

• Now I can add a task to the list to execute without other functions having to call it or be aware.
  
• No blocking (well except for serial, but it's the lowest priority) so now pauses (which used to nop for x milliseconds) just yield to other processes.
• Now I can build behaviors that can layer on top of each other and turn them on or off via a monitor/command line program.
• Sensors will run in their own task loops (like sonar) at set intervals which was more difficult to time with function calls especially when something new was added to the mix.

All in all I'm very pleased with this decision and I know it'll pay bigger dividends as my experimentation increases.

To do:

• Wire up the 4 IRPD sensors and 2 bump switches.
• Code a wall following behavior
• Code a avoid behavior (to drive/navigate) around an obstacle while still trying to get to a target coordinate :)

Other updates:

• I ordered a Lipo balancer for my battery. I got a great deal on the battery I use (4S 12C 33oomAH) and the replacement cost would be much more than I paid (thank you www.cheapbatterypacks.com) so I'm going to baby this one.
• Through typos I ran my motors full speed using the new RTOS code. The measured speeds were 90 ticks/ 20ms. The movie below shows the motors going 18 ticks/20ms so I plan to increase the max speed a bit. For shorter runs the code will auto slow the bot anyway, but this make longer distance "shorter" ;)
  

Jay

Video of new code. Here is a short video of the robot now. The 4 commands I set are:
go 5 5
go -10 3
go 0 0
go 0 1