Posted by Brian Hudson on April 8, 2009 at 11:51pm
Tom and I have made a couple of decisions and are moving forward."I would not be just a nothin' my head all full of stuffin'...If I only had a brain."I purchased and have received a standard Arduino Duemilanove board. I strongly considered the ArduPilot, but I wanted to get up an running quickly and I didn't really want to spend the money for an FTDI Serial / USB cable. I've been doing some basic bootstrapping to get a few things up and running.- A simple echo terminal program as my first "hello world" type sketch- A "random" number generator set up to send data to a terminal program on the PC- A C# program to plot the data received from the number generator. Which brings me to my first request for advice / feedback in this post:Does anyone have recommendations for a set of plotting / graphing tools? Tom has a student copy of MatLab / Simulink, so I was thinking about seeing what could be done there, but I want something we can both use without me having to try to find time on his computer. I've considered Processing, but I don't really see a way to interface it easily with other software packages, and while I can't sum up succinctly why, it just doesn't seem like a language I want to invest much in. For now I've just used a free-ware copy of something called PlotLab - http://www.mitov.com/html/plotlab.html. The docs aren't very good, and it doesn't seem all that well suited to my current task, but it lets me get something on the screen quickly in a nice friendly C# .Net rapid development setup. It has some cool zoom features as well.The last thing I've written is a little quick and dirty benchmark sketch for floating point operations. I was just trying to get a ballpark here, but I can't recall where I placed the data. Either way, this wasn't very scientific. If folks have data about the efficiency of the floating point emulation sitting around somewhere, I've done some searching and haven't found much. Otherwise, this could be the topic of its own short post, although I'm by no means an expert in this area.Moving along...Input! More Input!Just today I placed the order for an Atomic IMU 6DOF sensor assembly. This was a relatively big purchase for us, but the combination of sensors set up according to manufacturer recommendation, a great little form factor package, and a programmable AVR core seemed to really fit our needs.Under ConstructionThis brings me to my next planned task - I will be writing a simple software-serial pass-thru sketch so that I can hook up the Atomic IMU 6DOF to a terminal program on the PC, play with it, and chart the output at least as a simple benchmarking / verification setup (remember I was too cheap to buy the FTDI serial / usb cable).Following that, I think my next (larger) task will be designing a serial communication protocol between the main Arduino board and the Arduino on the 6DOF. I don't want to reinvent the wheel here, so once I spec what my requirements are, I'll be hunting around for something I can base my protocol on. Here are some characteristics that come to mind, but I'm definitely not saying these are exhaustive or all necessary - obviously some are mutually exclusive, and I have some decisions to make between them:1) High speed - I want to be able to pull data at as high a frequency as our processing / navigation model needs.2) Low latency - pull model - the main controller requests data, and it gets it fast. If we're sampling very frequently, I don't want latency to indroduce complexity or inconsistency into our control / feedback model. I haven't yet quantified this at all.3) Low encoding overhead cost (the pull model kind of pushes against this goal, as there's more back and forth than perhaps necessary)4) Simple and consistent frequency samples - push model - the IMU pushes data at a consistent interval. I like the simplicity of this, but I don't want to burden the main controller with servicing and throwing away serial data that it's not going to use, wasting precious cycles.5) Flexible and extensible - Right now, I'll be using this to pull raw data straight from the sensors, either with a push or a pull model. If I go with the pull model, in order to achieve low latency I'll want some sort of request batching and transmission mechanism, which I would want to lend itself well to future expansion of the data supported. This may all be overkill, and I might just end up defining a set of metrics on both sides that grows as my needs grow.Once I've got an idea of my data transfer system, another need I'll have is the ability to program the AVR on the 6DOF. I've got a couple important issues here, in priority order:1) Fail-safe, Fail-safe, Fail-safe. I'm a bit nervous about programming an SMD chip on a $125 part. I've never programmed an Atmel before (ok fine, I've programmed my Arduino several times now, but that hardly counts). My previous experience was with the PIC microcontrollers that took minutes to program and 20 minutes in a UV light box to "erase," so my guess is that ICSP is going to be a welcome change - I sure hope so, as I have no desire to screw this baby up and get my first shot at SMD soldering with my nearly non-existent soldering tools, and very limited soldering skills. Words of encouragement and "you can't break it by flashing it, I swear!" are definitely appreciated here.2) I'm cheap :) I'm not about to drop $20+ for an AVR programmer when I've got a 16Mhz amazingly programmable physical computing platform right in front of me! I've seen far more Arduino AVR programmer set ups than I expected to when I came up with this idea and did a search, so I'd love feedback about experience folks have here if any. What sketch program did you use? What software did you use with it? My Duemilanove has the ATMega328, so I'll need something current, I think.I'm hoping Tom will be writing a post similar to this about our progress on our choice of plane. Our ever current theme of getting the most for our money has led to a fairly involved spreadsheet with our candidate airframes, their characteristics, and the cost of all the equipment to get them up and running:
Thanks to Chris for the tip on fixing up this image so you can click it for a larger version. I have links to all the parts in the cells of the spreadsheet, but obviously they're too long to make fully visible, so folks looking at the image don't know what the dollar amounts translate into in terms of parts, but like I said - hopefully Tom will post on this later!
Thanks for the input, Tycinis! I am currently leaning heavily in favor of the AXN Floater Jet. I am hoping that we can carve out a little bit of space to put our processor and IMU when we get to that stage.
Brian, when you're embedding images if you click on "options" and then check "click for a pop up window", people can just click on the image to get the full size version. (You can edit your post and reload the image to get that if you want)
Comments