Rotation Is Being Sensed

Developing a rotation sensor has had a kind of ironic reversal. I started off with a light sensor. When that didn't work because of the jitteriness of light sensors, I tried a touch sensor. Not fast enough, so I switched from NQC to BrickOS. After some fiddling around, I got the touch sensor to be pretty accurate, but even at 5:1 (let alone the 15:1 I think I'll actually be working at) there was too much friction. Obvious solution: Use a light sensor! So I'm back where I started, but now running BrickOS.





The light sensor is still pretty jittery, but with the increased speed of BrickOS (at least 10x, maybe more) I now have the time to sample the sensor over a longer period to average out the wiggles. Taking 3 samples over 3 ms made the above pictured 5:1 ratio come out dead-on accurate even after 6 fast cranks of the big handle ( == 30 revolutions of the wheel, which itself has 6 light/dark transitions for each revolution, for a final "pulse" count of 180).

BrickOS is pretty awesome, but the documentation is totally non-existent and development seems to have stopped. But it works find as-is the the code is right there to examine, so I'll stick with it. Next I have to do a little experimenting and calculation to determine how much of a tilt translates into how much rotation and how fast those both occur.

Et Tu, Light Sensors?

I built a tube with a light sensor at one end and put a piston in there to see if I could get a linear response. I would call the success "minimal". The Lego light sensor just isn't made for (relatively) sensitive measurements like this.

So where does that leave me? As I understand the human vestibular system, there's really a ton of little binary touch sensors in there for the otolith to rub against. I can't use a ton of sensors with only 3 input ports, so I was going to measure the tilt more abstractly by comparing relative forces on just a few sensors. That's out, but I think I can still do better than the other two main balance systems out there.

(To reiterate: Checking to see if the robot is perpendicular to the ground is just wrong--not all vectors perpendicular to the local ground are anti-parallel to gravity. Using a gyroscope is better in that sense, but worse in a design and robustness sense. A robot should constantly be checking and responding to the real environment. A gyroscope is a form of dead-reckoning. As tiny errors build up, what exactly zeros it out? If the robot loses track of the gyro for a second, how does it recover? It's not that you can't fix these issues; just that you shouldn't have to.)

Here's the new idea: Rotation sensors. I mocked those early on because "the wheels need to rotate", but the sensor doesn't have to be on the wheel axle. It could be on the axle of a pendulum. When the robot tilts, it makes an angle to the still-vertical pendulum. That rotation can be captured.

There are a couple of practical matters:

• Stock rotation sensors only read off every 22.5°, which is way too small. It should be possible to gear a rotation sensor so that it reads a smaller angle, though.
• I'll actually need two of these to detect tilt in two directions. And I'll either need to make a "universal" pendulum that can tilt in both directions and report the angle in each or make two separate pendulums in a compact manner.
  
• I don't own any rotation sensors, they are like $30 each and I'm already in some trouble for spending too much on projects before I've gotten my allowance, so I think I'll have to make my own rotation sensors.
• A major pro- of this arrangement is that there's no need for complicated (for the integer-only RCX) trig, you can just multiply the number of rotational "clicks" times the number of degrees per click to get your tilt.

(Later: Just realized that a pendulum rotation system is also dead-reckoning. You have to keep track of the total rotation to know when you are upright. But at least it's a dead-reckoning from gravity and not from an initialized value. Also, while I'm actually going to pursue a system where the rotation is captured via alternating light and dark patches [pics as soon as I have something], you could also make it so the shaft encoder had a gradient proportional to the angle so it would be an absolute system, not a dead-reckoned one.)

Well. That's That.

The touch sensor otolith balancing system is not workable. A little experimentation shows that the touch sensor just isn't sensitive enough to small changes in pressure. It's basically a binary device even in raw mode.

However, it may be possible to salvage the system using light sensors. Light sensors?!? Yes, that's right. In the light sensor systems I derided, the light is being reflected off of the ground. That's still bad for the reasons I give. In a light sensor pseudo-otolith system, the light sensor just takes the place of a touch sensor. The touch sensor can't do small gradations, but the light sensor can.

I'm envisioning the light sensor (very tired of typing "light sensor" and "touch sensor" now) at the end of a short tunnel or cylinder. When the otolith shifts, instead of conveying that movement to a touch sensor via a lever, instead it moves a "piston" closer to the light sensor which registers the proximity.

Irony

I had an idea to build a device that would track the sun. And I wanted to take a video of it working, but not a video 10 hours long. At first I thought I could set up a tripod and take a picture every half hour, but that would only be 20 pictures, which is less than a second of video. Hey hey HEY, how about a Lego robot to automatically take pictures every 1 minute!

CamBot Mark 0 failed to press the button. A coworker gave me the idea to use pneumatics so I could get a better linear motion. I eventually got that built, but it wasn't strong enough. It was pretty cool, though. To save weight (and just be cool), I wanted to use a single motor to both pump up and pump down the piston. Here's a video of me explaining how that works:

So.....cool machine but totally useless. Then Mark II, which worked a lot better:

This one actually took pictures, which I could even stitch together into a movie, such as this test video:

Great stuff, Cambot! But here's the ironic part: The sun tracker never really did work well. Even after totally reprogramming it to adjust for differing sensor sensitivities and dampen fluctuations, it didn't ever do much better than this:

Practical Mechanical Matters

The Lego touch sensor has a very small range. After all, normally you only want to know it's binary value--am I touching something or not? Having a long range to traverse to find that out is counterproductive. But it's possible to put the touch sensor into raw mode (I hope think), which should give me the info I need.

Because the movement at the sensor has to be tiny (something like a few millimeters), I'm thinking of mounting the otolith on the long end of a lever. That's great, but it means the force will be magnified by the same proportion and the sensor has almost no resistance either. So the lever will also have to supported by something else to take the lion's share of the weight. Shock absorber?

And speaking of absorbing shocks, what about bumps? The contact forces will all go down (or up) at the same time, perhaps unevenly. I may have to specify smooth terrain. But how does a human do it? Is that why we have fluid in our ears, to keep things from rattling around in there?

(Of course, I'll probably have to specify smooth terrain anyway, since a wheel, especially at Lego scale, isn't very good for bumps.)

Simplified Free-Body Diagram

This is a free-body diagram for a robot that can balance in a single plane (i.e. forward and back only). The circle represents the "otolith" while the rectangles represent the sensors, which are mounted 90 degrees apart. In case you aren't familiar with free-body diagrams, it's basically just a device to keep a physics problem from getting too confusing. There are only three forces on the otolith--W the weight force, N1 and N2 the "normal" forces, i.e. the reaction forces from the ball pressing on the sensors.

T1 + T2 = 90
N1*sin(T1) = N2*sin(T2)
N1*cos(T1) + N2*cos(T2) = W

So combining the first and second equation:
N1*sin(T1) = N2*sin(90-T1)
N1*sin(T1) = N2*cos(T1)
sin(T1)/cos(T1) = N2/N1
tan(T1) = N2/N1

Therefore T1 = arctan(N2/N1). When the system is balanced, T1 should be 45, so the angle of tilt A = T1 - 45 = arctan(N2/N1) - 45.

(I could have done this with a single sensor, but then I'd have to deal with two more complexities. First, I'd have to set the otolith so that when balanced it is pressing the touch sensor about halfway so I can detect tilts in both directions. Second, I'd have to use the W vector in the derivation, which means I'd have to introduce real world units into the Lego program rather than simply using the readings them as-is. Two sensors lets me avoid that and also doubles the measurable tilt range.)

Ideas on Balancing

Ever since seeing Legway in action I've wanted to make a balancing robot, but my stock RCX didn't quite have the oompf to do it (that guy has some special proximity sensors). Then I read an article on Ballbot and knew that that's what I have to try to build.

But if I can't detect tilt in one plane, how am I going to detect it in two? I was originally thinking some kind of axle-mounted rotation sensor, but that won't work when the wheel is rotating (duh). The standard Lego solution for two-wheeled balancers seems to be a distance sensor in front and back, both pointed downwards. This is no good for several reasons:

1. I need front and back AND side to side (solution so use 4 sensors, but...)
2. The solution fails for slopes or obstacles
3. Other than the four-sensored jackal of Tingawahe, no real animals use this method
4. In the special case of a light sensor (instead of, say, an ultrasonic one), the ground has to be totally homogeneous in color and texture.
   

The standard non-Lego (but still robotic) solution seems to be gyroscopes (which Ballbot uses), but those suffer from a non-obvious problem: The rotation of the Earth. As the Earth turns the gyroscope stays still in space, which makes the robot fall over. There are calculations to counteract that, but still, no real animals do that either which should be a hint there's a better way. Also, it seems like it would be more robust to detect gravity directly, rather than have a requirement that you start out upright and keep track of everything since then (a kind of verticality dead-reckoning, when you put it that way).

"Real animals" got me thinking, though. What about those otolith dealies inside our ears? They detect gravity directly by having a little stone that rolls around and bumps into tiny hairs, which tells your brain which way is down.

So here's the idea: Rest a spherical weight on a "tripod" (think of holding a ball in your fingers like you are Merlin) of touch sensors so that they are partially pressing the sensors (this method depends on being able to get a range of values from a Lego touch sensor--I think that's possible). When the whole thing tilts, the weight on the sensors changes in a way related trigonometrically to the angle of tilt.