I just want to take a moment and give recognition to everyone who’s been commenting, private messaging, and even skypeing and facebook stalking me. I love talking robots with you and your advice about making this site better has been enormously helpful. Thank you!
Seattle Mini Maker Faire was fantastic! I talked to over 2000 people, most of whom asked the same question: “How does it work? Magnets?”
Maybe at the next fair I should use colored string so people grok it. I stayed overnight at the famous Green Tortoise across from Pike’s Place Market and met all kids of interesting people.
For instance, I’ve been admiring this Delta robot (called ‘Rostock’) for a while now. Turns out I’ve known the creator for years, and he’s even couchsurfed with me! What a tiny, tiny world.
Have you ever seen the gear heart? Emmett redid it with the Colbert head, just for fun. He had a good time teasing me about how gently I treated his ABS creations.
finally, here is a gallery of other things that were drawn at the Seattle Maker Faire, mostly on Sunday.
Optimization is the name of the game when attempting to solve the Travelling Salesman Problem (TSP). I’ve figured out most of what Lin/Kernighan is saying and then implemented it to run as fast as I can get it to go. Here’s the progress since the last picture I posted.
Here’s one of the Seattle skyline for the Seattle Maker Fair
It helps if you back up and squint. No really, it’s like pointilism paintings. Ever heard of the Group of Seven? Like that.
Here’s the results of the Drawbot working on the above image done by the TSP solver last night.
It ran for three hours and then failed when the laptop went into sleep mode while I was at the VHS. The mess in the top left is because I tried to draw the picture twice – once it failed when the stepper motor got warm and caused the bobbin to slip off the shaft. In a future version of the drawbot I’d like to try bicycle chain and sprockets instead of bobbins and thread.
Got any suggestions for pictures I should draw? Post ’em below!
Here’s an opencalc graph of the data I’m spitting out from the Arduino attached to the chip.
“A” values are accelerometer. “G” are gyroscope. The rest are based on the filter.pdf link above. I’m working on a live visualization in Processing. My first Processing app! Every day something new to add to the resume.
Edit: Then again, why reinvent the wheel? The Q&U Project Lab already has an open source Arduino, Processing, and C++ library that does all 9DOF heavy lifting. Plus I just learned how to make multi-file Arduino projects and the awesome #error precompiler for Arduino. Here’s a video of their code in action, exactly the same as I’m getting now.
Double win? Triple? Why do I feel like the word “tripple” should have three ‘p’s?
Excellent! Now that’s working, I’m going to tie the two together and use the sensor data to drive the wheels to keep the ball pointing in the desired orientation.
Wow! That title is a mouthful.
The chip is a Sparkfun SEN-10724 9DOF IMU breakout board
The library I used to read the chip is a collection of other sensor libraries. It talks to the chip using the i2c interface of the Arduino Wire library. Note! Arduino Mega 2560 uses different default pins for i2c. I wasted two hours before I caught that mistake.
The next challenge is that the filters produce a lot of noise and do not, by themselves, produce really meaningful data. The accelerometer and gyroscope have to be combined to get orientation information. The smoother the filter, the slower the results change, so a happy balance has to be “massaged” out of the system. Some filters:
http://en.wikipedia.org/wiki/Kalman_filter
http://code.google.com/p/9dof-orientation-estimation/
Here’s an example of what results SHOULD look like.
