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!
Read more…
Posted by Brian Hudson on March 31, 2009 at 10:24pm
My name is Brian Hudson. I've been wandering around DIY for a week or two now, and I've decided to start this blog to start interacting with the community, get feedback, and to track progress and thoughts on a project my neighbor and I are starting.My background is in Computer Engineering and Computer Science and I've worked in the software industry for several years now. My neighbor has a degree in Aeronautical Engineering, and we’ve been talking for awhile about a UAV project.In middle school and high school, I built a lot of models, eventually building my first R/C, the Sig Riser 100. This wasn’t an easy plane to start flying with around our large property, so I worked on a couple other models over time. My first flight at a true R/C field was a .40 trainer, although I wasn’t with a real instructor, and my first attempt at a landing ended with a nose dive of epic proportions :PBudget and time kept me from pursuing flight much further once I started college, but I always had a desire to get back to both model building and to get experience with R/C flying. I’ve always enjoyed watching aerobatic maneuvers, but never knew whether or not this would be something I could aspire to.As part of my Computer Engineering / CS degree, I had a design project requirement. A lot of other friends I had did things varying from simple lawn sprinkler controls to more complex client server software systems or mesh networked robots. I was fortunate enough to have a working relationship with a research lab where I was given a project to build a microcontroller based input / output multiplexing interface between an R/C car and an on-board 2 node Beowulf configuration of single board computers. The lab’s main area of research was computer vision and its applications toward studying human vision and neurology. Hence, the car had lots of sensors including web-cams, and the goal of my project was to make the use of this robot to test out algorithms and theories less painful – as you can imagine, grad students working on vision research were able to concoct plenty of algorithms and control schemes that flung this robot all over the place and crashed the onboard computers plenty of times. My project had several interesting features:- Ability to dynamically switch R/C control of the car between the on-board computing cluster and the received signal from the R/C transmitter. This also included the ability to pass “training” data to the computer, so that the computer could attempt navigation based on its video input, and could “learn” from corrections passed in by an observer.- GPS data input. This was another data point that could be read into the system and used for navigation and historical mapping etc.- On-board LCD menu and button interface. Basically, I had a small and simple library that allowed configuration of 5 on-board switches and which displayed a menu on a 4x20 LCD screen. This allowed for simple booting out in the field, with enough flexibility to run several different scenarios and simulations and store data to the onboard disks without having to drag along a keyboard and monitor. Now-days, the ubiquity of wireless networking probably makes this a little outdated, but it was handy back then - A serial protocol which allowed the controlling PC to configure the various peripherals like the buttons and LCD, read and write servo data, read GPS data and restart and recalibrate the various components in case the on board computer crashed in the field.I had a blast building this system, and it was really gratifying to start with a couple PIC microcontrollers in a tube, a few components, some flashing software and an idea and come out with a PCB design and some cool firmware to make this robot more fun to work with. I learned a ton through the whole process, and that’s part of the motivation for this project, to learn more about aviation, and get my hands dirty plugging some parts together.I think at this point autonomous flight is a pretty high goal, as I haven’t really (successfully) flown a plane myself and neither has my neighbor. But I’m certain we’ll have fun going through this process – probably have times of faster development and times of slower development, but overall we should have some fun.Ok – so let’s start with some operating parameters:1) Cost. We’re trying to stick within a fairly modest budget. I don’t think we have an explicit dollar amount limit, but at least from my end, I’m going to be working within my normal family monthly budget, which means I’ll probably be buying a few things each month to bring the project farther along (starting with the dev board and maybe the accelerometers or gyro, later adding GPS module, probably a couple of XBee’s for bi-di telemetry).2) Space. This one might sound a bit weird, but I live in a Condo, and my darling wife and baby don’t want me taking over a whole room with this hobby, so I won’t have space like when I was younger and building full kit R/C planes. We’ll need to start with some sort of ARF.3) Tools. Similar to space, I don’t really want to get in over my head as an electronics hobbyist here – I’m not afraid of soldering (although with a baby, I’m terrified of lead solder ), but I don’t want to have to set up a whole mini-electronics lab to get this project going. This is a big motivator for my microcontroller platform selection. Currently, I’m trying to decide between an Arduino Duemilanove or the ArduPilot. Duemilanove seems a little more flexible with the shield options and on board USB connector for programming, debugging etc. Yet, I like the fact that the ArduPilot has a dedicated on-board fail-safe microcontroller for R/C control muxing. I’ll have to look back at my college project to see how I handled input muxing there, because I’m pretty certain I had a channel on my radio that dealt with this – so I could probably re-use some of that design.4) No Glo. I’ve dealt with glo engines in the past with my models, and this was just simply too much hassle. I hope that the reduced selection of models and high initial cost of batteries, chargers etc doesn’t prove prohibitive to our budget, but I’m feeling pretty firm about this, and it seems like the rest of this community feels similarly.I’m not sure if there are any other major constraints here. I’m super excited about this, but also trying to keep from burning out by setting expectations initially too high or by getting frustrated by the fact that my time investment here will be subsequent to my day job and family life.So to conclude, I hope that hanging out on these boards will help me gain knowledge from the work of others, and to start with, I’ve got a couple of questions for others with experience here!1) Power supply – I’m looking to use an ESC with a BEC, but if I choose to use the Duemilanove, its power input requirements/recommendations have 6V as the minimum input supply. I believe the R/C standard is 5V. Now, I know that USB is 5V and the Duemilanove is designed to run from USB. Is there something I’m missing here? This is the first potential deal-breaker or the Duemilanove, and I’m really liking its potential here, so I’d love to find a “don’t worry about it” type of answer, even if it meant I might need to do some sort of power isolation for my servos (although that might generate more “help-me!” questions.2) Components – I’m looking for a simple starter set of components including wiring, a breadboard, some common LEDs, caps, resistors etc. Back in school, all of this came as part of the prototyping lab. Wow, I didn’t know how spoiled I was. I’m able to find many of these things piecemeal, and some of these things on sites like SparkFun, but especially regarding the components, it would be nice to find a simple kit, even if there’s some markup over ordering components from digi-key or something. Does anyone have a recommendation here?I’m looking forward to posting again with my next level of investigation, and I hope to hear from you all!
Read more…
