Quadcoptor Software Control

I haven’t quite yet forgotten about my quadcoptor project. It was on hold while I was schooling, but now that’s over I’ve picked it up again. I don’t currently have a good setup for the hardware, so I’ve been focusing on software. Specifically, the controller.

The controller dovetails quite nicely from the work on my thesis, which makes me feel a bit accomplished. Much of the research I did on underwater thrusters was based in part on propellers from aeronautics, so much of the same physics and controller properties apply. So the next thing I’m going to work on is this controller.

From the outset, I have a couple of goals for my design. First, the microprocessor I’m initially using is the Arduino, which is an AVR micro-controller. I suspect I’ll have to optimize out most of the added Arduino dev libraries and write everything by hand to get it to run fast enough, but I’m going to worry about optimization after getting the controller into a state I like. For the controller, I have three basic goals:

  • Auto-leveling
  • Position adjustment based on forward/reverse/up/down/left/right commands.
  • Heading/Tilt adjustment based on heading/pitch/roll commands.

The adjustments will be inputs of some sort, either manual or some high-level controller. The controller should be able to translate a ‘left’ command into appropriate changes to the propellers to move the quadcoptor appropriately. This isn’t trivial due to the under-actuated configuration, but it also isn’t terribly difficult either. I’d like to do it in software so that the pilot, especially a human pilot, doesn’t have to think about which propeller should be doing what.

The auto-leveling is there to keep the quadcoptor stable and aloft in the absence of other commands. It also makes for a helpful feature for manual piloting.

I’m starting with the auto-leveling, and will make decisions on the input controls based on that. That seems like a good enough decision to me, and it gives me a good place to start.

I decided to build the auto-leveler using quaternions instead of Euler angles. This seems like a good decision for a couple of reasons. For one, as expounded in many places, quaternions aren’t subject to gimbal lock as Euler angles are. For another, tracking and control via quaternions can be done without nearly as many trig functions, which are computationally expensive. (It’s possible I won’t need trig functions at all, which would be even better.) Also, I really want to wrap my head around quaternions and how to use them. This seems like a good way to do that. There’s a lot of research to draw on for both quadcoptor control and using quaternions, which I’ve found to be quite useful.

I started writing it all out in C. Since my workspace isn’t currently setup to work with the Arduino directly, I spent a bit of time building a debug environment so I can work on code compiled for x386 that can be easily switched to the AVR without much modification. Mainly it’ll be stubbing out hardware accessor functions to be written later. I spent some time digging through the AVR manual for things like register sizes and good C-types to use from the beginning to make sure I don’t get accidentally burned by something trivial. For example, the default ‘int’ size in gcc-avr is 2 bytes, whereas the default for x86 is 4 bytes. Simple things. (I’m sure there are plenty of other ‘simple things’ that will get me.) I also poked around at some of the hardware definitions to build some of my sensor structs correctly, though that’s getting a bit ahead of myself.

I realized, after specing out a bunch of code in C and testing it, that I could pretty easily write the same structure in Matlab and have all the fancy graphing tools add in for free for analyzing the controller. It didn’t take me very long to jump on that bandwagon.

At this point, I have the basic structure in place. I did some basic calculations on the physical properties of a quadcoptor (using the ‘spherical cow’ approach to estimating various things like mass, inertia matrix and such-like that maybe I’ll get more into next time) and now I can follow the path and rotation of my hypothetical quadcoptor and build my controller around it. And I can see the output with fancy graphs, which I’ve started to do.

There are a couple things I’m still missing. First, I’m assuming I know already the translation between ‘This is the force I want out of the propeller’ and ‘this is the input to the motor’. This is a non-trivial problem that will require some experimentation, which I’ll get to later. Second, I haven’t made any calculations on the physical properties of the motor itself. This would include the spin-up and response time to commands. I want to put in a basic model for these before I make too much headway into a controller design. My design currently includes a gyroscope, accelerometer and a height sensor so I’m sticking with those inputs so far, though that may change at some point.

So far, with not too much work (outside the significant amount of head-scratching involved to wrap my head around quaternions), I’ve implemented a basic controller. There’s been a significant number of sources I’ve pulled from throughout the internet, but the significant ones I’ve used I’ll point out here:

I implemented the basic attitude control from Fresk and Nikolaopoulos, but I haven’t spent any time tuning so it’s wildly unstable at the moment. It’s a nicely simple controller, but I may go a different route at some point. I’m going to play around with it some.

Next time I’ll show some of the work I did and possibly some graphs. Everyone loves graphs, after all.

Site Updates

Now that I’ve graduated and have a bit of free time again, I’m planning on going back to posting thoughts and projects here. Since it’s been a while since I’ve been on here, I’m taking a moment to upgrade, kick the tires, and make sure the windshield wipers still work.

Continuing the Saga….

I’ve been quiet while I threw myself into my Masters degree. Now I am finished, and have a degree in Mechanical Engineering, which I’m pretty excited about. Things I’ve been working on:

  • Mechanical Design
  • Low-Level Programming
  • Real-time Software
  • Ocean Sensors
  • Serial Communication
  • Matlab Analysis
  • Experimental Design
  • Automation and Control

I’m pretty excited about transitioning back into the professional world. And to getting back to my projects, including my writing.

More to follow…

Programming Methodology

As I design code for my ROV, I’m discovering something: my brain is
set in Object Oriented mode. The solutions I think of work well for OO
programming. But there are problems with this:

  • LabView is not especially good for OO programming. 1

  • Some of the hardware I’m working on doesn’t allow for it (or allows
    it in a very limited way).

  • I’m working at a low enough level that I should be thinking about
    things like the overhead that OO programming adds.

The take-away here, which is important, is that I’m trying to
architecture something such that it isn’t a complete mess (especially
for the next poor soul who has to deal with my code), and that each
component is testable on its own.

This turns out to be more difficult than I’d like it to be. There are
lots of little decisions I have to make about where to do X thing,
where the control loop for Y thing happens? How do I log all of these
things correctly while both running individual components and when
running the master program? How do I do it without copying code all
over the bloody place? How should I pass data around for logging, and
for all the other things I need to do?

I’m sure these are solved problems by people who are much smarter than I.

As an example: the data logging. I want data to be logged. I want to
do it when I’m running a module individually. I want to have the same
format when I run it from my master program. In the past, I’ve used
Log4j, or Log::Log4perl, or whatever tool is appropriate for the
[OO] language I’m using. These tools were built by people with much
more knowledge of the language than I and they work.

I have an idea of how they work. I could reproduce them in an OO
language, though limited in scope to the above packages. But for my
current application, these are difficult.2 I have various
requirements I must meet. I can meet them simply, but I also want to
do it such that my code is not a terrible mess and can be changed
without terrible repercussions on the entire structure.

I have a variety of little problems like this. I’m learning. I’m
improving. This is in addition to the various annoyances I have with
LabView, and I’m still learning LabView. But it’s something I didn’t
anticipate when I started. I’ve worked on procedural code before
(namely C).

Once again I step back and look at the over-arching code to decide the
best method of achieving my goals. I do it regularly. I hope to not go
too far down any of the rabbit holes I find.

Footnotes:

1 I think I’ve said enough about LV at this point so I’m not going
to belabour the point.)

2 I should note here that the purpose and needs of logging are
somewhat different in my current system. But that’s an aside to my
point here.

Labview Woes

It’s been a tough week on the LabView front. I’ve spent some
frustrating hours on what should be some simple things. According to
the internet these are simple tasks. In reality, though, they seem to
not be so simple. The issues I’ve run into (in brief):

  • There doesn’t seem to be a simple way to synchronize clocks between
    two devices. The first way I tried, the somewhat manual way,
    suffered from lack of documentation. Other than brief snippets like
    ‘use this method along with this other method’. No order of
    operations. And the name doesn’t help. ‘Set Time From Reference’ ->
    Does this mean it checks the reference and sets the local clock, or
    does it mean set the local clock to use that as a reference.

  • So what about NTP (or simple NTP). Labview supports it from four
    versions ago. No problem, right? Except by ‘supports it’ it means
    ‘scour the internet until you find the updated version of the
    module that has it included because the module we provide doesn’t
    include it’. Automatic updating did not help. What’s the point of
    automatic updates if you can’t get the latest version of the
    module? And then, when I do find it, it still doesn’t work. I (and
    my lab-mate) have spent no small amount of time on this.

  • Object Oriented programming in LV is somewhat limited. All I want
    is an abstract class, or maybe a virtual class. ‘All subclasses
    must have this method. It must take in these things, it must output
    a map/hash.’ What I thought was the LV version of a map/hash —
    wasn’t. The entire purpose of the class was to create a template
    for all the sensors.

  • Of course, that might be a moot point anyway. To run on the FPGA,
    the only allowed data type is the Integer. And that’s the entire
    point of the exercise after all. The upshot of this little gem of
    information is that the code that’s already written to read and
    parse the data from the sensor won’t work. I either have to not do
    it on the FPGA (which somewhat defeats the purpose of our using
    the FPGA), or re-write the code. If the latter, at least I have a
    template. Right?

All in all, not the best two weeks on LV. I’ve learned quite a lot. I
have not, however, made much in the way of progress.

This is the life of a programmer.

LabView and Low-Level Programming

Building a control system is a bit new, I admit. Not completely, but the
models I’ve used in the past are in Python or Octave. And I’ve a bit
of experience with C, Java and Perl in terms of programming.

Once upon a time, many long years ago, I learned LabView. It’s sort of
like Legos, you find the function you want by browsing through icons
(much like sifting through the Lego bin). You plunk it down and wire
it together and you’ve got a program. I do mean wire, by the way. It
looks like the visual representation of spaghetti code. But you can
create your own functions pretty easily which helps cut down on that.

Now, I learned it way back in my first round of college. At that time
I knew Perl and a smattering of C. It’s really good at creating a
scientific-looking UI, with buttons and dials and oscilloscopes. The
back-end… well, I like typing more than I like plunking things down
with the mouse.

But LabView is what we’re using because the hardware we have is from
National Instruments and runs LabView natively. It seems to be the
standard, and not C as I was expecting hoping. But, when in Rome and
all that. (I mean, that’s how I picked up Python, C# a wee bit of
Visual Basic and Ruby. I’m adaptable that way.)

So I’m going low-level with a graphical programming language.

The main thing I’m doing is adapting the control system we have from
one piece of hardware (PXI) to another piece of hardware
(CompactRio). Both are interesting in different ways, and I’ve not
used either of them before. (I’m used to a *nix server based somewhere
in the distance where I move little bits around. Or throw little bits
against other bits in an attempt to break things. But in a systematic
way.)

This, it turns out, is not so easy. Part of it is the learning curve
on my part, I’m sure. It’s an unfamiliar language. And I’m doing
unfamiliar things with it. Even with the Arduino I was mainly using
slightly higher-level C functions. The closest thing to this was
on the Motorola 68k, back a few years ago. I wrote a real time OS
(albeit a simple one), so the concept isn’t unfamiliar.

So I’m spending my time trying to read sensors. I figured it out
pretty well on the PXI – the old hardware. I was reading in sensors
and sending data up to the workstation (my desktop). I could see it
coming through, and I could log it. It was pretty cool.

But the PXI is much like my Windows machine. Things are familiar, more
or less. It has more serial ports, more dedicated functionality, but
there are reasonably high level function boxes to deal with it.

The Compact Rio is a FPGA. Not quite a computer in the same way, I
have discovered. It requires a little special handling. Which, really,
is kind of cool because I get to go down and get my hands dirty in the
nitty-gritty.

Well, as nitty-gritty as you can get in a picture-based view of the
world. This is what I’m working on now. The goal is to get the ROV
back in the water by the end of February. I think it’s achievable. I’m
getting along well, for the most part. Though it would help if I
didn’t run into various LabView bugs. At least I have enough
experience to not spin my wheels too long on these sorts of problems.

That’s what I did last week, in terms of my research project. This
week is pretty much more of the same. I’ll try to make the next post
slightly more interesting, though.#+TITLE: Week 05 – 28 Jan

Patch Cables

Short note on patch cables. They’re the wires used to connect things up on solderless breadboards. I got a mess of them in the microcontroller kit, all different colors. I do enjoy the color coding.

Thing is, I’m having the same problem I had way back when I was a freshman in college: my cables are too long. 90% of the time I need a much shorter cable than what I’ve got. But I don’t have any other patch cables, and these are so nicely color coded.

Cutting these down won’t work very well. They’re twisted core and I want solid core. I’m going to start hunting around a bit to see if I can find a package of multi-colored wires somewhere. I could just buy a roll of solid core wire, but the color coding is very useful.

If I don’t find some, breadboarding my larger projects is going to be a huge mess.

Quadcopter Parts List

I started by making a spreadsheet of everything I would need to purchase, cost and links to the product pages. I also separated the list out into Brain, Body and Tools.

The brain is where I’m more comfortable, being a programmer. I’ve done a little embedded programming before (Motorola 68k), but I’m excited to try out this new Arduino project. They’re relatively cheap, easy to use, and have lots of support on the internet. This seems like the perfect opportunity to try it out.

I purchased a kit, which included not only the microcontroller but a whole bunch of little doodads, whats-its and wiring. Yeah, I probably won’t use everything in the kit but I’ve got to start somewhere and I don’t have much in the way of this stuff lying around. I added a few accouterments as well. (I spent quite a lot of time clicking around MakerShed and Sparkfun. So many things!)

Though not directly related, the other thing I purchased was an e-book on Arduino programming and projects. It didn’t include anything revolutionary, but it did help me navigate the libraries and setup of the hardware. And they were fun projects.

The body is a little more complicated. It involves a lot of things I am entirely unfamiliar with, namely hobby helicopter parts. I used an online calculator to figure out roughly what size of rotors and motors and such that I’d need to get the thing off the ground. I ended up with 8′ rotors, with motors and electronic speed controllers (ESC’s) to match. Most of this is right off of Aeroquad’s site.

I also needed a battery, a charger for the battery and a power supply for the charger. (The last two are sold separately. I’m sure there is a reason, but I do not know why. On the other hand, the charger is pretty fancy looking.)

I decided to use XBees for the wireless transmission. I spent a long time deliberating between Series 1 and 2. I ended up getting Series 1 because my needs are simple and I can move up for my next project. Series 2 is a drop-in replacement anyway, so I can upgrade if needed. I’d like to eventually work with the Series 2 for the networking capabilities (multiple bots working together), but that’s still in the future.

In addition to the XBees, I got a couple of XBee breakout boards. I can solder these into the project and pull out/replace/upgrade the XBees themselves as needed.

I already had a couple of prototyping boards, which I intend to use for soldering all the electronics together, in addition to the wiring and soldering. I did get some thicker wires and heat-shrink tubing for connecting to the ESC’s and motors.

Last, I purchased a Wii Motion Plus for the gyroscope and two Wii Nunchucks for the accelerometers. One of the Nunchucks is intended to be the controller. (Amazing things. When I did my thesis, over a decade ago now, acquiring an accelerometer was one of the more difficult tasks.)

I didn’t need too many things for tools. I’ve had a soldering iron and helping hands for years (waiting to be used for far too long). I also have small screwdrivers and a solder-less breadboard (in addition to the two that came in the microcontroller kit). I picked up a nice static bracelet, since the one I had was paper and cheap. I rather like the new one. I got an XBee USB programmer.

I picked up a WiiChuck Adapter connector. I thought this was a pretty nice way of testing out/prototyping the Wii accessories before ripping them apart. This turned out to be more useful than I originally anticipated as Nintendo uses special screws to hold their hardware together, a Y-Wing screw (unrelated to any space ships). They’re cheap on Amazon, though I still haven’t purchased one.

That leads me into the other thing I hadn’t quite grokked: I didn’t get everything in the first round. There turned out to be little things I needed but didn’t anticipate in addition to the things I knew I was putting off for later. The y screwdriver is an example of one of those things.

I intentionally waited on getting the main body of the quadcopter, the pieces that would fit everything together. I’m also intending to get a smaller Arduino board or a clone to actually put into the quadcopter. The prototype board is great for testing everything out, but I want to be able to use it for other things as well.

I’m also pretty sure I’m going to need a voltage regulator or two, possibly some resistors and diodes for such things as de-bouncing and other such real-world technical issues. But for now: experimentation and building!

Robot Army: Quadcopter

The robot army is coming along, if slowly.

I started, recently, on building a quadcopter. For those who don’t know what a quadcopter is, well… check them out. They’re pretty awesome. I’m working on a prototype at the moment. I don’t know yet if I am going to build more, but I’ve got ideas of what I want to add should I do so.

For the moment: basic quadcopter.

I started by searching far and wide through the internet for plans and instructions. I didn’t really consider getting a kit, though they exist. What fun is that? All the pre-packaged parts that you know are going to fit together, with calibration software and all that jazz.

No, I wanted to do it the fun way. Maybe it has something to do with my Patrick McManus camping tradition.

That isn’t to say I’m not following instructions. I’m a masochist, but I’m also inclined to succeed. I’m following two main sites: Aeroquad and wiicopter, both of which have lots of instructions and parts lists and whatnot. For the most part I followed the parts list on the Aeroquad site, but I’m pulling the accelerometer and gyroscope from the Wiimotes.

The other change I’m making is to use another Wii Nunchuck for steering, rather than one of those Time-Traveling Delorean Remotes those sites feature.

I’ve divided the project into two main components: the brains and the body. I’m considering each more or less separately at this point.

I will admit at this point that I don’t know what I’m going to do with a quadcopter, but boy do I want to build one. I’ll turn it over to Roe when I’m done and let her play with it.

The Bechdel Test

I’ve been thinking about the Bechdel Test in relation to my most recent stories. I’ve been writing again, which is good. But I wonder if my stories pass this particular issue. I thought I’d do a bit of a recap.

The one I’m working on now, other than The Gods of Reed, is a short story (though growing more than I originally intended.) There isn’t much conversation to speak of, my protagonist is too much of a loner. But it’s first person, so it’s somewhat a conversation (monologue?) with the reader.

Very little of this dialogue excludes the antagonist, a male. She thinks about nothing else throughout the story (maybe a few lines about her family and some notes about magic). Personally, I would have a hard time thinking about pretty much anything but my stalker, should I acquire one. Especially one that delights in taunting. This may change later when she *does* start interacting with someone (there are plans). Not sure how that’s going to go yet.

The Gods of Reed, my other on-going story, is third-person limited with a male lead. He spends a lot of time talking about himself, his own relation to the world, his rapidly diminishing memory and sense of self, etc and so on. But very rarely do we see two females interacting. (It does happen in very brief moments, but if I recall correctly their conversations are centered around aforementioned male lead.) There is a lot of story, but I’m pretty sure it doesn’t pass.

The last story I worked is a bit more difficult to pin down. It features characters with… interesting gender dynamics. The main character did, at one time, share a female-shaped body with another consciousness. I think of her as more or less female, as far as one can think of AI as gender.

The other character… I don’t know. That character is of mixed gender: male bio-half, female AI. Though this is mostly in my head, I don’t think any of this comes across in the story at all. (It actually is a short story, two pages, and it isn’t necessary to the plot so I don’t feel bad about this.) Mostly the story interacts with the female AI aspect of the Cyborg and the AI. And their conversation has nothing to do with males, so much as determining their own senses of self given the changes they underwent recently.

So in that sense, it may pass the test but it is somewhat debatable. Perhaps I would give it a half-pass?

The other story set in that universe, a previous NaNoWriMo novel, didn’t have a plot to speak of and isn’t worth dissecting.

The last story I will consider is another novel, one that has a plot and several interesting characters. The protagonist is female again, and has a very clear goal though is somewhat distracted by a male romance. She interacts quite a bit with another female character, her main rival. They bicker (fight) constantly, but mostly about their methods of scouting and information gathering. They rarely talk about their respective romances, or about any male save for ammunition. So of the stories I’ve considered so far, this is the only one that clearly passes the test.

I find it to be an interesting experiment to consider my stories through various lenses. It’s an interesting way to measure it up in terms of character development and world-building. I may do something similar with these, and other stories, as I think of different lenses to use.