Reviews of Stuff

FF is being a critic today:

Filet mignon: Sounds so classy, no? It turns out it's just a rather imprecise name for a part of the cow. Is good to eat, though perhaps not worthy of the quality its reputed for. Still, very tender. We broiled it over a bed of mushrooms and onions (which subsequently became delicious).

Duck broth: Buy a roast duck. Eat the duck. Boil the scraps. The first batch came out nice and strong and we used it to flavor a rice porridge. SC is saving the skimmed fat for a duck schmaltz experiment.

The Imaginarium of Dr. Parnassus: Not as good as The Fall. No cohesive plot and the visuals weren't good enough to carry it.

Opportunistic potato baking: Oven was preheated after the broiling, so we put in some potatoes to take regeneratively capture some of the heat. But it wasn't enough to cook the potatoes. We ended up microwaving them an additional 6 minutes.

And finally, perhaps the instigator of all this:

Hendrick's gin: Very flavorful, indeed. Advertises itself as "not for everybody" and comes with a pamphlet that helps you feel elitist about drinking it. Haven't quite gotten past the juniper berries, though. So I don't know about this whole cucumber thing. So far, I've only tried it on the rocks and with a little Collins mix.

Sadfish :(

We found the littlest cowfish (who sought medical attention a few weeks ago) dead today...we don't know if the bigger cowfishes (cowfish = panda cory) are bullying him or if he was terminally ill or unable to eat or what. :(

ARHS running in MATLAB

Dissatisfied with the DCM approach to coding orientation (in particular, I don't like the renormalization step), I switched the algorithm over to quaternions. And today I finally fixed a bug in the quaternion multiplication code that was causing coupled rotations to not work properly. Maybe I should have just done Euler angles for this first approach...

Also I switched to a pair of complementary filters instead of the extended Kalman filter. The problem with using Kalman is that it's not a simple matter of noise when combining the sensors. The gyro is probably well-described as having Gaussian noise, but the accelerometer and magnetometer see lower-frequency disturbances: translational acceleration and distortions of the earth's magnetic field caused by nearby magnets and high-μ materials. So when it comes down to it, I really do want to specify crossover frequencies.

The accelerometer is the only thing I trust at DC, because it has the least bias drift, but above 0.2 rad/s (arbitrarily chosen) I'll be picking up the maneuver acceleration in the tilt sensing. I trust the magnetometer at higher frequencies, up to the point where magnetometer noise is comparable to gyro drift. I chose 2 rad/s.

This is complicated by the fact that the accel and magneto can only read error in two axes, so I augmented the accel attitude error estimate using the magneto attitude error estimate, and I augmented the magneto attitude error estimate using the gyro signal (because I trust the gyro more than the accelerometer between 0.2-2.0 rad/s).

Anyways, it looks pretty good! Next up is some mounting hardware and porting the code to the AVR.

Noise!

Thought I was closing in on getting the AHRS squared away (plenty of difficulties on the way), but I attached it to the helicopter today and looked at the signal with the main rotor running (with the helicopter still on the ground).

Lots of noise. Can't tell what is electrical (tried shielding it; but the experiment wasn't very well controlled) and what's mechanical (i.e., vibrations transmitted to the sensors). So :(

Helicopter is here!

The helicopter arrived yesterday! Today I tried flying it manually. A couple of things:

1. Am afraid to get it too far off the ground, so it's kinda like a hovercraft right now, scooting around on the ping-pong ball landing gear. Am trying to get a hang for the cyclic controls, but I my response is phase-lagged.
2. It does seem to be a bit easier to control when it gets off the ground more. Maybe then the attitude change would be more pronounced (right now the landing gear constrains it), and then it'd be more responsive.
3. I think I've got a better feel for the transfer function. 
1. In theory (i.e. according to my book), cyclic input tilts the rotor disk, generating a pitch/roll moment, which is 1/s² to pitch/roll angle. The combination of disk angle and body angle vectors the rotor thrust, producing a lateral component to the downdraft, which is 1/(s+a) to velocity, which is in turn 1/s to position.
2. In practice, the extended landing gear is tripping me up: I'm not getting any pitch/roll, so I have 1/s² from control (disk angle) to position, but the gain is really low. And then when I get slightly off the ground, the pitch/roll dynamics come back into play, which makes it 1/s⁴ from control to position, and my heavy-handed control turns into an obscene body angle.
3. So maybe an SAS (Stability Augmentation System) that turns the cyclic command input into a desired body angle would be useful. Then letting go of the stick would return the helicopter to level.
4. The heading-hold gyro works really well.
5. I may want to retain direct control of the throttle (i.e. not give it to the SAS). Due to the CCPM, though, a cyclic-control SAS will also have to control the collective, but that should just be a kinematic thing.

As for the ARHS, have had some issues. 

1. Gyro integration wasn't working so great with combined motions, so I looked into the calibration and have some minor adjustments there. 
2. Was displeased with the quantization error on the accelerometer, so I decided to sample at a higher rate with a digital lowpass. 
1. Can't do it with their I²C library because the send/receive code is all blocking, and getting the acc data requires 0.81 ms (9 bytes at 9 bits/byte at 100kHz SCL). So if we sample the acc at 200 Hz and the magnetometer at 50 Hz, that's 4 ms out of the 20ms we have per cycle.
2. Wrote a non-blocking I²C library (with a pretty clever instruction queueing system). Took 5 hours, then accidentally deleted it. Completely gone. That sucked. Don't do that.
3. Read about quaternions. They're pretty elegant, so I'm thinking I will switch the AHRS from being DCM-based to quaternion-based. Have started deriving the matrices/functions that I need for an EKF.
1. Does my 8-bit AVR at 8 MHz system clock have the computing power to run an EKF?
2. Will I need to write optimized matrix multiplication code?
3. Will I need to convert all the math to fixed-point?

Magic wand

FF made a magic wand. It makes others do your bidding. You operate it by holding it in your hand and hitting them on the head.

Also, Pixieglass! SC thought it should be called pixie glass, so she took some and went back in time with it. She showed the medieval villagers the unbreakable glass and told them it was made by pixies. But then when Otto Rohm patented a manufacturing procedure to make synthetic pixieglass, he called it Plexiglass in order to be able to trademark it. The irony!!!

Software frustrations

Spent all day dealing with stupid software. Well, not all day. Did go see a $6 matinee (How to Train Your Dragon, very cute) and have a nice lunch outside (beautiful day today), but the rest of the day was pretty crappy because of this software thing.

First: installing libavcodec. Have svn, so tried installing from the ffmpeg source code. Have cygwin, tried that to no avail (couldn't get the right compiler settings to run ./configure). Tried to install MinGW and MSYS, but MSYS install involves picking and choosing from a myriad of packages; didn't want to figure that out. Got a precompiled Windows binary; that didn't help. Finally found ffdshow, which installs ffmpeg and everything was good.

Next, opening the .m2ts file to create an AVS script for MeGUI still doesn't work. And can't open in graphedit, either. Re-installed Haali, didn't do anything. Frustrating.

Anyways, I finally gave up on that particular file. Turns out I can open other ones okay, so to hell with it.

Next: the sf9domahrs AHRS code. Arduino IDE keeps wanting me to move it into a different folder with the same name as the .pde file. And then it can't find any of the other files. No header files anywhere, wtf? Finally realize that if the main .pde file has the same name as the folder it's in, then opening it in the IDE automatically includes the rest of the files in that folder. Gah.

A vista point!

We've driven up and down 280 many a time and have noticed the "Vista Point" signs in the past, but today we decided to follow one. Turns out there's a walking/biking trail along the Crystal Springs Reservoir. There's barbed wire fences on both sides to keep you on the path, but it's quite pretty, and parts of it really reminded me of the Columbia Trail back home.

We saw a lot of little lizards, a cool mountain stream running down a bunch of moss-splattered rocks, and a small sort of inverse-peninsula where the water came in surrounded on 3 sides by land, with one side sloping very gently (must have flooded recently; grass is still visible underneath the water). Also these giant plants with seed dispersal features that look like giant paintbrushes. SC found them ideal for bopping people.

Orbital gyrocompass: pretty awesome

So, on a satellite, it turns out to be pretty easy to detect the horizon and thus calculate pitch and roll angles. Yaw is harder. However, if your satellite is orbiting, then your LHV (locally horizontal-vertical) frame will have a steady-state rotation around the LHV frame's pitch axis, which creates gyroscopic coupling between roll and yaw. That is, a term containing the orbital rate and the yaw angle shows up in the body frame's roll rate, and a term containing the orbital rate and roll angle shows up in the body frame's yaw rate. So if you have a measurement of roll angle and roll/yaw rates in the body frame (and you know the orbital rate), then you can estimate yaw angle!

The even awesomer part is that when the dust has settled (Prof. Rock demonstrated this with a complementary filter; Bryson uses "a kinematic estimator (a steady-state Kalman-Bucy filter)", which I am having some difficulty reconciling with my conception of a Kalman filter), you end up constructing the yaw angle estimate by adding a bunch of lowpassed measurements! That's pretty cool. It's like my IR sensor + gyro estimate of angle for the Segboard project.

So is this applicable to the helicopter? Well, let's look at the equations for the orbital gyrocompass. The linearized relationship (discarding higher order terms) between Euler angle rates and angular velocity in a circular orbit with nominal orbit rate (and therefore nominal pitch rate) n is:

• dΦ/dt ≅ p + nΨ
• dΨ/dt ≅ r - nΦ

where Φ and Ψ are roll and yaw angles, and p and r are the components of the angular velocity vector in the body roll and yaw axes, respectively. The nΨ and nΦ terms come about because unless the body and LHV frame pitch axes are identical (i.e., Φ,Ψ = 0), the orbital rotation in the LHV pitch axis shows up in the angular velocity vector, even if dΦ/dt and dΨ/dt are zero.

Of course, the fact that n is quite constant and Φ, Θ, Ψ are perturbational quantities only (i.e., small) makes the math a lot simpler, but the concept should be generally applicable: if an axis and rate of rotation is known (n about the LHV pitch axis, in this case), and we know an Euler angle (roll Φ), then the gyroscopic coupling makes the unknown Euler angle (yaw Ψ) a major component of the discrepancy between the known Euler angle rate (dΦ/dt) and the corresponding component of the angular velocity vector (r).

You know. Unless large angles and high rotation rates bring the unknown Euler angle or Euler angle rate inextricably back into the equation. Or ill-conditioned transformation matrices (gimbal lock!) ruin everything. Also this is all hoping that the magnetometer will produce a clean, trustworthy heading measurement.

Also it looks like I will have to do some SMT rework to remove a highpass filter...

update: Looking closer at the schematic for the board I bought (v14), it appears the RC component values for the HP are 0 ohm and "Do Not Place", so no rework needed!

Arduino tools!

I got the arduinoscope up and running. It took some doing...if you want to run the source code (which I needed b/c the default COM port was wrong), then you need to get Processing and put all the code in the "libraries" folder of the . You'll also need the library controlP5. Also don't forget to install the Arduino FTDI driver.

The arduinoscope is pretty cool. It's pretty slow, though. I might be able to look at servo pulses by switching it to digital mode only (hmm...I wonder if it has a trigger function...), but I don't think it'll do things like measuring microsecond-length pulses to time code execution. So I may have to write my own anyways...goals are:

1. Auto-reset trigger function
2. 6 channels with 10 us resolution, for servo signals
3. 1 channel with 125 ns resolution, for code timing
4. New data format to convey this to client
5. Client function to measure and display pulse length

It'd be nice to be able to switch between the two operation modes without loading new code, but I'd settle for two different programs.

Next up: inline assembly for the Arduino. This page outlines the basics, here's some Arduino-specific examples, and here's someone who eventually got fed up with the Arduino bootloader and bought an AVR programmer. Let me just remind myself why I'm not doing that: (1) would need to get C compiler and programmer running, (2) would need to build the hardware. Hmm...I may have to do (2) anyways for the servo controller. And there must be a billion forums and tutorials on how to do (1). Aaargh...think simple. But Arduino workarounds aren't simple. Gah. We'll see.

And finally: interrupts. This is a pretty exhaustive tutorial that uses the ISR vectors, the Arduino folks recommend attachInterrupt(), which I'm skeptical about, and here's a great article on timing the Arduino interrupt overhead.

Some final thoughts: If I want to implement a Kalman filter in the AHRS, I'll need matrix inverses. Of somewhat large matrices. And I'll need to do it on an 8-bit processor running at 8 Mhz. I guess I can run simple linear filters at the ADC refresh rate and then run the estimator at 60 Hz. Anyways, looks like I'll have to brush up on numerical methods for fast matrix inverses. Also, write some highly-optimized matrix multiplication code.

Optical flow and hardware considerations

So it looks like getting data off the SparkFun CMOS cameras may be harder than I initially thought, due to poor documentation. Also, it'll require a pretty fast processor (or an FPGA) to do the optical flow calculations. So let's hope it doesn't come to that.

Did some more digging, sounds like this servo controller will have to be a microprocessor. So I'm thinking I'll just run everything off the Arduino for now. Then all that goes on this extra board will be level shift ICs.

APCircuit's boards are cheap but shipping is stupidly expensive. So I may just get extra boards fabbed: one with a PIC servo controller with SPI to the Arduino and SCI/UART debug lines open, and with a camera and a DSP microprocessor or CPLD. Heh, and then I might as well put in micro SD capability for aerial photography...

As long as we're talking boards, maybe one for a 2-axis accelerometer? Or if I find one with a digital interface, maybe just solder straight to the pins, pot it in epoxy, and call it good.

Hey, why not do that with the level shift ICs? Bundle it into a cable: 5 sets of 3-pin plugs or sockets for the servos/ESC, 8 wires (6 signal + 2 power) into a harness for the receiver, and 13 wires (6 input + 5 output + 2 power) into a harness for the Arduino. Maybe 14 wires for the Arduino (5V in and 3.3V out). An inside the bundle will be 2 level shift ICs and some capacitors.

So no boards for now.

E-sky King V3 it is!

Bought the E-sky King V3! In red, unfortunately. Ugly, but it'll have more visibility in the air. And for the price saved, I could have bought a set of blue parts, so it really didn't seem worth it. Yay!

More AHRS thoughts

I had a moment of panic when I thought about deconvoluting the accelerometer's measurement of tilt (a positive nose-up pitch θ adds a positive gsinθ in the x-axis accelerometer reading) from its measurement of translational acceleration (a positive forward acceleration also adds a positive a_x into the x-axis accelerometer). The scary part is that positive pitch requires forward cyclic to return to hover, whereas forward acceleration requires aft cyclic to return to hover, so distinguishing between tilt and translational acceleration will be important to the control system.

In the short run, we can deconvolute the two by integrating the gyro signal to get attitude, but gyro drift makes this infeasible in the long run. In the long long run, our plant tells us we can have a steady-state tilt but not a steady-state acceleration (unless we're flying in a circle...hmm...), so we might be able to deconvolute the two that way. I'd need a good plant model in the estimator, though. Even so, I think it'll all hinge on the gyro drift.

What about other methods of attitude sensing? If we can solve attitude sensing, running optical flow on a downward-pointed camera can tell us a lot about velocity and altitude. Maybe more cameras? On the sides, for horizon sensing? Infrared horizon sensing? Two downward-pointed cameras to generate a parallax field, assuming a flat ground? What if the surface is too low-contrast (like grass)? Or not flat (like a hillside or building)? How much can the magnetometer tell us? What about adding accelerometers? This particular problem is a fundamentally about perceived acceleration in a non-inertial frame, but adding another accelerometer at a different location on the helicopter would give me angular acceleration, which could improve the gyro readings...

One last thought: do we try to integrate the human more? Maybe the goal here is not to strictly stabilize, but to slow down the dynamics to the point where the operator can take over these difficult sensing problems. In this case, (assuming the goal is a hover) the operator would distinguish between forward acceleration and nose-up pitch by his choice of control input.

AHRS

That's "Attitude and Heading Reference System", and the next big part of the helicopter project (possibly the biggest part, if this off-the-shelf solution doesn't work out).

The plan is to use this board from SparkFun: it contains a 3-axis accelerometer, 3-axis gyro, 3-axis magnetometer, and a ATmega328 processor with bootloader setup for in-circuit serial programming. And at least one group has built an AHRS out of it. I haven't looked through their code, but if they're at all competent it should give some indication of the board's capabilities.

What I'll need to evaluate is its susceptibility to drift (this is the big one; I think this'll be what ultimately limits the system's performance) and the level of noise (also problematic, but at least I have ways of dealing with it). When I get to the stage of implementing the control system, I can add the plant dynamics into the estimator model (I wonder if the microprocessor is up for calculating Kalman gain matrices) and that should only make it better, right?

Next steps:

1. Get the thing running with the pre-flashed firmware. Check that output values are reasonable and look for drift. Also try running it in the refrigerator to check temperature compensation.
2. Install the AHRS code and evaluate its performance. If necessary, write some client software to display its output (maybe MATLAB or Java, for easy graphics).

And on the Arduino side:

1. Get Arduino talking to servos (will require 3.3V to 5V hardware)
2. Get Arduino talking to receiver (will probably require 3.3V to 5V hardware). An oscilloscope would be nice.
3. Get Arduino talking to both at the same time (try powering everything off helicopter 5V regulated supply)

In terms of hardware, will need something with enough connectors for the servos and receiver, as well as 5V to 3.3V level shift. And for integration:

1. Get Arduino talking to AHRS (over software SCI at first, then try SPI)

And that should be it. Arduino mini has 18 I/O pins available, need 3 for SPI, 6 inputs (from receiver), 6 outputs (to servo, ESC). That leaves 2...which I might use 2 for I²C to a camera module. Hmm...I guess I should take a look at serial interface servo signal drivers...I might even be able to find a 5V driver with a 3.3V serial interface.

update: No magical chip to read/output servo signals. My search mostly turned up tutorials on how to implement it on a PIC or AVR, which is probably a bad sign. A 12-bit PWM generator might work: at 60 Hz, I'd get 8 bits of resolution for pulses between 1 ms and 2 ms, which is...okay. Well, I can control the output timing to have no overlaps, so I guess I could deal with the output latency of a shift register or I/O expander. That saves 3 or 4 pins.

Ultimately, anything involving measuring or generating a precise servo pulse would require a crystal or else a clock line from the Arduino. And programming a PIC (and therefore designing ICSP into the servo I/O board) would be more trouble than it's worth. Right?

update 2: ATmega328 doesn't have a bajillion input capture/output compare channels like the HC12. Also, it's an 8-bit processor! How quaint. It does allow any I/O pin to trigger a pin change interrupt, though, so I can use that ISR with a free-running timer to measure pulse lengths. And I'll stagger the output pulses.

Also, I don't really need the extra pins at all. This count just shows that I have exactly as many as I need. And if I really need to, I can cannibalize the SCI Tx/Rx pins.

Insulation

The day before yesterday it finally got warm in our apartment, recalling the summer days when we'd open the door and all the windows at dusk to exchange in the cool air. It seems so long ago...

But then today it rained and there was no sun and it was cold. I'd turn on the heat, but it just seems so ineffectual...you hear it burning gas, and the room warms up briefly but cools back down to steady-state in an hour or so. As a result, we've spent most of the winter being cold, bundled up in sweaters and/or blankets.

So up on the list of apartment search criteria (for next time): double-pane windows and doors that close properly.

More helicopter options

Looked around some more, people on the Internet seem to bash on the E-flite CP series quite a lot. The options now seem to be:

E-flite CP+
$200 at D&J Hobby, $180 online
528mm main rotor, 298 g
3-in-1 (mixer/ESC/gyro) module
FM receiver
11.1V 800 mAh Li-Po
370 brushed main motor, N30 tail motor

E-flite CP Pro 2
$230 at D&J Hobby and online
515mm main rotor, 325 g
2-in-1 (mixer/ESC) module, G110 heading lock gyro (11 gram)
Spektrum AR6100 2.4 GHz receiver (DSM2)
11.1V 800 mAh Li-Po
370 brushed main, direct-drive N60 tail

E-sky Honey Bee CP 3
$100 online only
525mm main rotor, 410 g
3-in-1 module
2.4 GHz receiver
11.1V 1000 mAh Li-Po
370 brushed main, direct-drive tail

E-sky King 3
$160 online only
600mm main rotor, 390 g
All discrete components
2.4 GHz receiver
11.1V 1500 mAh Li-Po
400 brushless main, shaft-driven tail

E-sky Belt CP V2
$170 online only
680mm main rotor, 670 g
All discrete components
2.4 GHz receiver
11.1V 1800 mAh Li-Po
450 brushless main, belt-driven tail

The advantage of the E-flite models is that they're available (and so are their replacement parts) at a nearby retail store. Its disadvantage is that it is rather expensive.

Of the E-sky models, I appreciate how cheap the Honey Bee is, but I think the King's discrete components may be easier to work with. It's also a bit bigger, but what does that mean? The Belt is bigger still, but that's starting to get into uncomfortably-big territory. I still need to figure out where to fly this thing.

So, E-sky King it is? Will have to sleep on it, but that looks like the winner for now.

update: xheli.com and eskyhelicopters.com have the King 3 for $186 and $195, respectively, with tax and shipping. helidirect.com has it for $160 (no tax, free shipping), but they only have it in red. These seem to be the only U.S. distributors. Oh noes!

Also, saw a video of the E-flite Blade mSR. It looks really fun...

Cowfish, back from the hospital

We put the littlest cowfish back into the main tank. We did a full treatment of erythromycin (4 days) then kept him in quarantine another day and a half, feeding him flake and small pellet food, both of which he seemed to like  very much (at least much better than the shrimp pellets).

Once back in the tank, he found the other cowfishes and they seemed to get along all right. I'm still concerned about his missing pectoral fin, but there's nothing we can really do about that.

Helicopter update

Looked around some more; I think the E-flite Blade CP Pro 2 is the one I want. I saw an older model (CP+) at D&J Hobby, and it looks pretty good. I'd originally thought a fixed-pitch heli would be better, but it looks like there aren't any good ones on the market.
It's got a 6-channel receiver that feeds into a motor speed controller (for the main motor and the tail motor), which has an integrated gyro (which might be okay; I'll just account for it when closing the control loops). But it's not one of those integrated receiver/motor controllers, so that's good. Brushed motor, so no tach signal, but that shouldn't be too hard to add. It's got electronically mixed CCPM, which is good, and better yet, the transmitter can be switched out of that mode (into unmixed elevator/aileron/collective signals).
I'll have to decide, though, whether to go for the one at the hobby shop or to try to get a CP Pro 2. Will have to call around to see who has that in stock. I hope it'll be okay with the weight I plan to add. I guess one advantage to a modular gyro is that I can remove it to save weight.

Talked to Prof. Rock about the project. He thinks the helicopter dynamics won't be too bad, but sensing will be difficult. First, there is the issue with accelerometer drift when trying to get a good attitude reading. We'll see how that goes. I'm curious, too, about how the magnemometer pans out.
Next there is the issue of velocity sensing. Ideally, the user is dealing with a velocity command. He thinks it'd be pretty interesting to run optical flow on a simple webcam. Checked Sparkfun, and it looks like it'd be doable in terms of price and size. Will need good attitude and altitude information to decouple pitch/roll from x/y translation, though. Hey, maybe with good attitude and perceived x/y translation, I can get altitude... And as an added bonus, it becomes an aerial photography platform.
Finally is the issue of the ideal user interface. Can we get by without velocity sensing? My argument is that humans have trouble dealing with 1/s² plants (i.e., issuing a force command) because the system is underdamped, so we just need damping. Or, recasting the human interface question in a different light, what if we take the human to be a simple proportional controller? The user has a desired position, and he issues a command based on the error he sees. If it's a velocity command, that's great, because it's a first order system. If it's an acceleration command, then with insufficient damping and human time delay, it'll be unstable. But we should be able to deal with that, right? What I like about this approach is that it takes advantage of the human's sensors and puts that into the loop.
Oh, one final thing that I thought would be cool: if the magnemometer works well for heading, then we could interpret all cyclic commands in a fixed (w.r.t. yaw) reference frame, thereby freeing the user from orientation considerations...

Helicopter buying considerations

Backordered the Sparkfun parts. Now to look at a helicopter.

There are lots of sites with buying guides for beginner fliers. But I think what I'm looking for is slightly different because I'm looking for a helicopter that will be easy to close a control loop around, which may not necessarily be one that is easy to fly by hand. Or will I need to learn how to fly it by hand before handing it over to the control system? I hope not...

For one, bigger helicopters are supposed to be easier to fly because everything happens more slowly. That might not be as much of an issue with the control system. Not only is its reaction time much better than mine, it will have access to acceleration data (an idea: get another 2-axis accelerometer and mount it a distance away from the main IMU, to get angular acceleration) whereas a human operator only sees position.

Now, what about fixed vs. collective pitch? Cost and crashworthiness are both still extremely relevant, which suggests fixed pitch. What about the controllability? Fixed has one fewer control input, and the variable rotor speed is going to wreak havoc on the cyclic control transfer functions, which I suspect are strongly influenced by rotor speed (may need to install a rotor tachometer).

I guess we'll look more closely at the cost, then. It may also be important to get one with separate electronics so that I don't have to hack into some integrated receiver/motor controller module. And for this, the dumber the electronics, the better.

Soda is hypertonic!

So I was thinking about how I need sugar, or maybe acid, in my drink to really make me feel like my thirst is quenched (just drinking lots and lots of water doesn't seem to do it). And perhaps that's due to highly successful manipulation by soda companies, because soda (carbonation + sugar + acid) seems best at quenching thirst.

Anyways, I'd heard that drinking soda actually makes you more dehydrated. Is that true? The can of Sprite in front of me has 38 g of sugar in 355 mL of solution. At a molar mass of 180 g/mol (for glucose/fructose), this comes out to 0.59 M, or 590 mOsm/L. A saline solution has 9 g of NaCl (58.4 g/mol) per 1 L of solution, i.e. 0.154 M. And it dissociates completely, so it has an osmolarity of 310 mOsm/L.

So it's true! Well, maybe not. According to Wikipedia, urine has an average osmolarity of 500-800 mOsm/L without really trying (i.e. with a restricted fluid intake, healthy individuals produce higher concentrations). So maybe you're still hydrating when you drink 590 mOsm/L Sprite (I'm not counting the citric acid or carbonates, but my gut feel is that those are negligible compared to the sugar). The scary part is that it's just about half the concentration of 3.5% salinity sea water (35 g/L NaCl = 0.6 M = 1200 mOsm/L).

Update: SC points out a pretty fundamental flaw in my reasoning: sugar is special. There is active transport and all sorts of metabolism and other reactions that happen, and your kidneys try very hard not to even get any into the glomerular filtrate. So we can probably ignore the sugar, which most likely makes soda hypotonic. It'd be different if it were a 590 mOsm/L salt solution.

Helicopter project

I'm officially getting the helicopter project off the ground (so to speak). The goal is to build an auto-stabilizing (via active electronic control) R/C helicopter. Or rather, since I plan to buy a 5-channel ready-to-fly helicopter, the goal is to build an electronic control system that will interface with the helicopter's existing actuators and radio  receiver. Some thoughts on various parts of the project:
Interfacing with the helicopter: For this, I really need to buy a helicopter and get access to an oscilloscope, but if it's anything like the R/C plane I'd played with, then it's all PWM servo control signals, which will be easy to work with. Helicopter should also have a 4.8V battery back for the control electronics, and/or a 3.3V regulator on board?
Sensors: SparkFun has a pretty nifty sensor: 3 axis accelerometer, 3 axis gyro, 3 axis magnetometer, and an ATmega328 chip w/ bootloader, all on a small 3.3V board. The only downside is that it's $125, but I guess you have to bite the bullet somewhere. These sensors are expensive and tend to come in hard-to-solder packages (where all the pins are on the bottom). Board printing is not too cheap (AP Circuits $20 for a small board + $40 shipping; ugh) and doing the board design and programming an on-board microcontroller...it's just too much for now.
The other option, though, is to get an Arduino (which I'll need anyways) and some accelerometer or gyro breakout boards: they're not much more expensive than the sensors alone from DigiKey or Mouser, and it saves a lot of trouble. They have analog output, which is easy to read but prone to noise. (some might have PWM? Will have to look again to check for serial).


Next step: Well, unfortunately SparkFun is out of 3.3V Arduino Pro's and FTDI USB-Serial breakouts, so I'll just have to wait on that. Looks like buying the helicopter is the next step...

Cowfish!

The littlest (what? The spellcheck isn't complaining? "littlest" is actually a word?!) cowfish (read: Panda Cory) is not doing so hot. We found him laying on his back yesterday, but a tap on the glass scared him back into a right-side-up orientation. A few minutes later, we found him sucked into the filter intake, but after turning the filter off he swam away.
Worried that he was infectiously sick, we quarantined him, and that's when we noticed (1) the water has a distinct blue-green tint and has an ammonia concentration of 0.25 ppm and (2) this fish's spine is a bit bent (though he seems to be able to straighten it) and he seems to be missing a pectoral fin.
So we did a 30% water change (the spare-tank setup makes this easy; dump the new water in the spare tank and it gets cycled into the populated tank over several hours) and hoped for the best.

This morning the cowfish still seems okay. I put in a small shrimp pellet, but I think that was a bad idea because I came back to see him doing barrel rolls in the quarantine bowl. The bowl (a yogurt container floating in the main tank) is pretty small (860 mL or 0.23 gallons). So I netted the fish out and replaced the quarantine water with main tank water. He looks okay now. I don't know how we're going to feed him, though. Maybe the algae wafers will be better. Or we could give him flake food, because there's nobody to compete with him.
He is showing some fraying at the ends of his fins. Fin rot? Or physical damage? If it's physical damage, is secondary infection an issue? So we decided to dose him with antibiotics (E.M. erythromycin).

Here's the plan: the package calls for 1 packet / 10 gallons (at 200 mg/packet, this makes a 5.3 ppm solution), once a day for 4 days. We're going to make a concentrated solution (21.2 ppm) and mix that into the quarantine water. What should be our target concentration? What concentration vs. time profile does the recommended dosage produce?
Wikipedia says erythromycin is metabolized through methylation in the liver and eliminated through bile, with a  half-life of 1.5 hours. But we have a very small fish in a lot of water, so is metabolism significant? Are there other things that may metabolize erythromycin? What about elimination? The instructions are very clear to remove any activated carbon filters during treatment. So without any metabolism or elimination, and with the specified water changes:
Day    ppm
  1    5.3
  2   10.6
  2*   8.0 (after 25% water change)
  3   13.3
  4   18.6
  4*  14.0 (after 25% water change)
This article gives 370 mg/kg as the LD50 for erythromycin injected into rainbow trout at 13°C. That's a pretty high upper limit. So even if "no metabolism/elimination" isn't an accurate assumption, it may still be a safe one...

update: SC pointed out that it actually wouldn't be too hard to split up the powder in a packet into 4 equal sized doses, so we'll just do that. We'll dose the water in a bucket at twice the specified concentration (so, 1/4 packet an a time into 1.25 gallons) and then dilute that by 1/2 when mixing into the quarantine bowl.

Tire adventures

Tires! Our front right tire was squeaking, and we had no idea why. But we decided to let it be because the squeaking would go away after a few minutes.

Gradually, though, it started to be accompanied by a vibration. You could feel it even at very low speeds, but it seemed to go away around 25 mph, and wouldn't come back until highway speeds.

Then yesterday I drove SC to the airport and it was pretty bad up at 65 mph. I hadn't driven the car in a while, so I couldn't tell if this was much worse than what it used to be. It'd also pull to the right (indicative of higher drag on the right wheel), which I didn't remember it doing before. On the way back, it was decidedly worse than it had ever been before: at a walking pace I heard and felt a periodic thumping, and at higher speeds it became a vibration. At medium speeds I guess the suspension took care of it.

When I parked, I took a look at the tire, and pretty luckily, the damage was on the part of the tire facing up, in plain view. It looked like a part of the tread was dented in. What?

To cut to the end of the story, it turns out these tires are 14 years old, the tread had separated (we're very lucky it didn't do so catastrophically), and I was looking at a bulge (from the side I was viewing it initially, it was hard to tell whether one part was abnormally high or whether another part was abnormally low) where it was hemorrhaged out (the steel belts had broken). Also spent 10 min. pumping up a flat 60 psi spare using a bike pump. I'm glad our spare is actually functional now...

Took it to America's Tire in Redwood City, got it replaced in 30 min. for $50 plus $22 labor+fees, and the dudes there were all right.

Oh, right: this time it was the front right tire. This had happened previously once before, with slightly different symptoms, to one of the front tires (don't remember which one...that's why this blog is necessary). They'd rotated the older new tire to the left rear wheel, and so this time they rotated the newer new tire to the right rear wheel.