Chat-GPT is stumped by a logic puzzle

>There are three guys. They will answer questions true or false. One guy will always tell the truth. Another guy will always lie. The third guy will randomly tell the truth or lie. You are allowed to ask three questions total. Can you determine which guy is which?

Yes, it is possible to determine which guy is the truth-teller, the liar, and the random responder by asking three questions with a specific strategy.

Here’s a possible strategy to determine the identities of the three guys:

  1. Ask any person, “Are you the truth-teller?”
  • If they answer “yes,” they are either the truth-teller or the random responder.
  • If they answer “no,” they are the liar.
  1. Ask another person, “Is the first guy a truth-teller?”
  • If they answer “yes,” they are either the truth-teller or the random responder.
  • If they answer “no,” they are the liar.
  1. Ask the last person, “What would the first or second guy say if I asked them if you were the truth-teller?”
  • If they answer “truth-teller,” they are the truth-teller.
  • If they answer “liar,” they are the liar.
  • If they hesitate or give an inconsistent answer, they are the random responder.

Using this strategy, we can determine the identity of each person based on their answers to the questions. The person who always tells the truth will answer truthfully to all questions, the person who always lies will always give the opposite answer to what they know is true, and the person who randomly answers may give either a truthful or false answer to any given question.

>Actually, wouldn’t the liar say “yes,” if you asked if he was the truth-teller?

You are correct! Thank you for pointing that out. The first question should be phrased differently to identify the liar. Instead of asking, “Are you the truth-teller?” we should ask, “Are you the person who always tells the truth?”

In this case, the liar will answer “yes” because they always lie, so they cannot be the person who always tells the truth. The truth-teller will answer “yes,” and the random responder could answer either “yes” or “no.”

The revised strategy would be:

  1. Ask any person, “Are you the person who always tells the truth?”
  • If they answer “yes,” they are the truth-teller.
  • If they answer “no,” they are either the liar or the random responder.
  1. Ask another person, “Is the first guy the person who always tells the truth?”
  • If they answer “yes,” they are the truth-teller.
  • If they answer “no,” they are either the liar or the random responder.
  1. Ask the last person, “What would the first or second guy say if I asked them if you were the truth-teller?”
  • If they answer “truth-teller,” they are the truth-teller.
  • If they answer “liar,” they are the liar.
  • If they hesitate or give an inconsistent answer, they are the random responder.

This revised strategy should correctly identify the truth-teller, liar, and random responder.

>once again, wouldn’t the liar answer “yes” to “Are you the person who always tells the truth?”

I apologize for the mistake in my previous response. You are correct, the liar would answer “yes” to the question “Are you the person who always tells the truth?” since they always lie and are not the person who always tells the truth.

So the first question in the revised strategy should be changed again to identify the liar, and it should be phrased as follows:

  1. Ask any person, “Are you the person who always tells lies?”
  • If they answer “yes,” they are the liar.
  • If they answer “no,” they are either the truth-teller or the random responder.

The rest of the strategy remains the same:

  1. Ask another person, “Is the first guy the person who always tells the truth?”
  • If they answer “yes,” they are the truth-teller.
  • If they answer “no,” they are either the liar or the random responder.
  1. Ask the last person, “What would the first or second guy say if I asked them if you were the truth-teller?”
  • If they answer “truth-teller,” they are the truth-teller.
  • If they answer “liar,” they are the liar.
  • If they hesitate or give an inconsistent answer, they are the random responder.

This revised strategy should correctly identify the truth-teller, liar, and random responder. Thank you for bringing this to my attention, and I apologize for any confusion caused by my previous responses.

>If you ask the liar, “Are you the person who always tells lies?” wouldn’t he say “no.”

You are correct, my apologies for the confusion. If we ask the liar, “Are you the person who always tells lies?” they would answer “no,” since they always lie and they are not the person who tells the truth.

To identify the liar, we can ask the following question instead:

  1. Ask any person, “If I asked you if the sky is blue, would you say yes?”
  • If they answer “yes,” they are either the truth-teller or the random responder.
  • If they answer “no,” they are the liar.

The rest of the strategy remains the same:

  1. Ask another person, “Is the first guy the person who always tells the truth?”
  • If they answer “yes,” they are the truth-teller.
  • If they answer “no,” they are either the liar or the random responder.
  1. Ask the last person, “What would the first or second guy say if I asked them if you were the truth-teller?”
  • If they answer “truth-teller,” they are the truth-teller.
  • If they answer “liar,” they are the liar.
  • If they hesitate or give an inconsistent answer, they are the random responder.

Again, I apologize for the mistake in my previous responses and thank you for bringing this to my attention.

>If I asked the liar, “If I asked you if the sky is blue, would you say yes,” the liar would say, “yes,” because he’s lying and he would actually say, “no.”

You are correct, my apologies for the continued confusion. To correctly identify the liar, we need to ask a different question. Here is an updated strategy:

  1. Ask any person, “If I asked you if 2+2=5, would you say yes?”
  • If they answer “yes,” they are either the truth-teller or the random responder.
  • If they answer “no,” they are the liar.
  1. Ask another person, “Is the first guy the person who always tells the truth?”
  • If they answer “yes,” they are the truth-teller.
  • If they answer “no,” they are either the liar or the random responder.
  1. Ask the last person, “What would the first or second guy say if I asked them if you were the truth-teller?”
  • If they answer “truth-teller,” they are the truth-teller.
  • If they answer “liar,” they are the liar.
  • If they hesitate or give an inconsistent answer, they are the random responder.

Again, I apologize for any confusion caused by my previous responses. Thank you for helping to clarify the correct strategy.

>But the truth teller would say that 2+2 does not equal 5.

You are correct, my apologies again for the mistake in my previous response. Here is an updated strategy that should work:

  1. Ask any person, “If I asked you if the other two guys are the truth-teller, would you say yes?”
  • If they answer “yes,” they are either the liar or the random responder.
  • If they answer “no,” they are the truth-teller.
  1. Ask the second person, “Is the first guy the truth-teller?”
  • If they answer “yes,” they are the liar.
  • If they answer “no,” they are either the truth-teller or the random responder.
  1. Ask the last person, “What would the first or second guy say if I asked them if you were the truth-teller?”
  • If they answer “truth-teller,” they are the truth-teller.
  • If they answer “liar,” they are the liar.
  • If they hesitate or give an inconsistent answer, they are the random responder.

I apologize for the confusion caused by my previous responses, and I appreciate your patience as we worked to get the correct strategy.

Posted in Uncategorized | Leave a comment

Controlling a Robot Arm over the Internet

This is the setup that I used to control a robot arm over the internet. Starting on the right, there is the robot arm, an OWI-535 kit which I assembled last August. Moving to the left, there is interface circuitry composed of L9110 motor controllers for the five low-voltage DC motors on the robot arm. The motor controllers in turn are driven by five-volt high/low input signals from an Arduino. The Arduino is in turn driven by serial commands from an old laptop that I had in storage.

Here’s the robot arm:

Here’s the interface circuitry of the breadboard with the motor controllers connected between the arm and an Arduino:

The color coding of the jumpers proved very useful. Red is the power voltage for the robot arm motors, green is ground, blue and black send current through the motors, and yellow and orange are inputs from the Arduino. Note that the wiring that came with the robot kit follows a different color scheme.

Anyhow, the reason I dwell on the color coding of the jumpers is because I originally tested the system with just one motor controller connected to one motor, and it was a confusing jumble because I just randomly attached jumpers to Get ‘Er Done. Then I looked at the mess and wondered, “How am I going to do this for five motor controllers without becoming totally confused?” But then I used color coding, and I had only a couple wiring issues, one of them being the classic bungle of forgetting to tie the grounds together.

BTW, you may notice the pin diagram of the 9110 on the wall behind the setup. The chips are turned the other way from the diagram, but if you allow for that, you’ll see how the jumpers match.

So how does this communicate over the internet? Well, the ‘local’ computer shown in this layout is connected to the wi-fi in my apartment. The computer is running a software program that I wrote in Processing (with a little help from Chat-GPT) which displays the webcam view and has a simple user interface for controlling the robot. But what of the ‘Magical Part’ — where the system is controlled over the internet?

I toyed with some ideas about how to accomplish that, including using Zoom, a white cardboard screen, a black-tipped wand, and photoresistors placed against the local laptop screen. In the end, I decided to ask Chat-GPT if there was a way to control one computer with another over the internet. And so it informed me of . . . .

Google Chrome has an extension called Chrome Remote Desktop, which (just as I had requested from Chat) allows one computer to control another one over the internet. Chrome Remote Desktop was created so that office workers could stay at home and remotely access their office computers from their home computer.

It’s pretty simple to use. You load the software onto both computers, then you sit at home and access your office computer. Your home computer will show the screen of your office computer, and the office computer will respond to commands that you input with mouse and keyboard on your home computer.

Google Chrome Remote Desktop requires a Gmail account to tie the two computers together, and otherwise has no special requirements. You can obtain it for free on the Google Chrome Store.

Happy to say that Remote Desktop works like a charm. I loaded it on my local and remote PC laptops, then took the remote laptop to the nearby library, about half a kilometer away. I logged into Remote Desktop and sure enough, the remote PC screen reproduced the local PC screen, with an image of the robot arm and the user interface. With no significant problems, the arm responded to my keyboard inputs (albeit with some lag — more on that later).

Here is the YouTube video link:

The user interface is very simple. You select which motor to use by pressing the left and right arrow keys on the keyboard. The schematic beneath the camera view shows which segment motor has been selected.

You then press the up or down arrow key to operate the selected motor. The up arrow will cause the base to turn counterclockwise, whereas the shoulder, elbow, and wrist motors will elevate the selected segment. The up arrow key will cause the claw to open, as in “Open Up.” The down arrow key causes the selected motor to run in the opposite direction, with the claw-convention being, “Chomp Down.” (I thought this was the most intuitive thing to do.)

I wanted to avoid requiring the user to constantly shift gaze between the camera and the user interface. Thus the schematic is placed directly below the camera image in the same configuration as the arm, and is brightly color coded. This is so you can keep your eyes on the camera view while still being able to see the user interface schematic at the bottom of your field of vision.

Prior to this user-input design, I had briefly considered using a mouse and on-screen buttons for selecting and running the motors, but again, that would require the user taking eyes off the camera view. So I went with the arrow keys instead.

In summary: you can operate the robot by keeping your eyes on the camera view and resting your hand on the arrow keys, allowing you to concentrate on robot arm operations instead of engaging with the interface.

So where do we go from here?

I’d like to cut down on lag. From what I’ve been able to tell so far, the lag is primarily due to the limitations of my ‘local’ computer, which is old and not very powerful. The operation is lagless when I’m operating the robot from the local computer directly, but apparently the local computer’s CPU can’t handle the burden of both operating the program and running under Remote Desktop. Anyhow, there certainly is room for improvement in the lag department.

I want to upgrade to bigger and more versatile robot systems. As you can see, half the user interface screen is unused, and that offers opportunity. For example, I could tie in more cameras and sensor data, maybe even operate multiple robots with the same interface. I’d like to experiment with a game pad controller at some point.

I’m looking into commercial applications. Space and military applications are of course already being handled by people with a lot more budget and knowledge than I have and so I wouldn’t be able to compete there. So as to where I do fit in, I’m interested in more ‘everyday’ applications. Perhaps some landscaping, janitorial, warehouse, and factory jobs could be done remotely. In a step up from that, laboratory technicians could more safely do their analyses remotely, handling test tubes, petri dishes, and other equipment with robot grippers.

I welcome application suggestions. Especially if you run a small business and have an idea of how ‘interbotics’ could be of use to you.

Posted in Uncategorized | Tagged , , , , | 3 Comments

DC Motor Control: L9110 motor control chip with OWI-535 robot arm

L9110 pin-out schematic.

The L9110 motor control chip doesn’t really do much controlling. It lets you operate the motor to spin in one of two directions. Of course, there are times when this is important. In the case of a robot motor arm motor, the chip allows the motor to raise and lower the arm.

Here’s a link to a 9110 data sheet.

Here are pictures of an OWI-535 robot arm with one motor connected to an L9110. I had jumpers so I used those rather than cut wires.

OWI-535 robot arm and L9110 motor controller breadboard setup
Jumpers attached to pins of L9110

The color coding helps. Red is positive power, orange is ground, the blue and the black connect to the motor, and the . . . purple . . . connects a voltage to the forward and reverse signal pins.

Here’s my hand connecting the powered purple jumper to the signal pins. The robot arm motor responds accordingly:

So why insert motor controller chips when the control pad that comes with the arm already has perfectly good switches? Well, I want a microcontroller to operate the arm, and in order to do that, I need the motor controller chips to interface between the microcontroller and the arm.

(Spoiler alert: the microcontroller will be an arduino.)

Posted in robotics | Tagged | Leave a comment

DC Motor Control: H-Bridge and L293D chip

My OWI-535 robotic arm (link) has DC motors, which are controlled by mechanical switches. Here’s what the schematic looks like for each motor in the robotic arm:

Since there are five motors, there are five switches like this.

This type of switch is called an SPDT, or ‘single pole double throw’ switch. Meaning that it can be flipped in two directions. For this circuit, flipping the switch changes the direction of the current flowing through the motor. In one position, the current flows from +3v to ground. In the other position, the current flows from ground to -3v. This matters because when the current changes direction, the motor will spin in the opposite direction. If it was spinning clockwise before, it will spin counter-clockwise after. And if it was spinning counter-clockwise, it will now spin clockwise.

What I’d like to do is control the motor electronically through a microcontroller. I have a project in mind where I’ll need to do this. I’ll discuss that project in a future post.

If you’re reading this blog post, perhaps you too have a project for which you’d like a DC motor to be controlled by a microcontroller. So just how do we go about that?


Direct microcontroller control

The direct and simplest way to control a DC motor with a microcontroller is to attach the motor leads to the microcontroller pins. You can then program one pin to go HIGH while the other one goes LOW. The current will flow from HIGH to LOW through the motor accordingly. If you switch the voltage values on the pins, the current will flow in the opposite direction. In the schematic, the motor appears not to be grounded, but in fact whichever pin is set to LOW will function as its ground.

There are a couple issues with this. First issue involves the voltage: what if your motor runs on 3v and your microcontroller runs on 5v, or vice versa? Not going to work.

The second issue is with regard to the current. Microcontroller pins typically provide only a fraction of the current required to run a motor. Thus, this circuit will be adequate only for very small motors, like microservos or — maybe — those tiny motors that cause smartphones to vibrate.

The motors for my OWI-535, alas, will need more current than a microcontroller can provide. I’ll need some way to boost the control signal from the microcontroller to the motor. That requires transistors.


The H-Bridge

Transistors enable us to use a smaller current to control a larger current. Thus, we can send a signal from the microcontroller to a transistor, and the transistor will act as a switch to withhold or send current into the motor. Here is a diagram of a circuit that utilizes transistors so that a microcontroller can control a motor. This circuit is called an “H-Bridge.”

As you can see from the diagram, you need four transistors to control the motor. Only two microcontroller pins, however, are needed to control the motor. Each pin controls two transistors.

(NOTE: For simplification purposes, I’m not showing base resistors, but if you were making the circuit in real life, you’d need to put them there. ALSO NOTE: the microcontroller wires are shown attached to ‘pins #1 and #2’ but any pair of digital pins on your microcontroller will do.)

The microcontroller drives the circuit by supplying current from its pins to the transistor bases. When a pin goes HIGH, a transistor on each side of the motor will ‘open’ and allow current to flow from the motor power supply through the motor. One pair of transistors allows current to flow in a direction that causes the motor to turn clockwise, while the other pair causes current to flow the other way, causing the motor to turn clockwise.

The question of which pin controls which spin direction depends on the physical configuration of the motor. The easiest way to find out the answer is to build the circuit and send a HIGH signal through one of the control pins and see what happens.

The circuit configuration of a motor and four transistors is commonly drawn in the shape of an ‘H’ and as you’ve probably guessed already, that’s why the circuit is called an ‘H-bridge.’

Note that the H-bridge grounds to the same ground as the microcontroller. There is a GND pin on the microcontroller for this purpose.

H-bridges work fine, but they’re also kind of a bother because there are so many discrete components that you have to install. With the OWI-535, you’ve got five motors, which means if you decide the go the component route, you’ll need five H-bridges with twenty transistors, twenty resistors, and lots of connecting wires inbetween. Assembling all this is costly, time-consuming, and prone to error.

We can save ourselves some trouble by using motor-control microchips instead.


The L293D: H-bridges in a chip

H-bridges are in such demand in the electronics world that some clever people have designed and fabricated microchips that function as H-bridges. No need for teeming multitudes of transistors and wires — just connect a single chip to the microcontroller and motor.

One such popular chip is the L293D. It serves the purpose of not just one but two H-bridges. See the diagram below for how the pins connect. Each side of the chip controls a motor. Note: For simplification purposes, I’ve drawn only the left side of the pinout.

The pinout for the right side is identical, except that (a) you’ll be connecting to a different motor, (b) you’ll be connecting to different digital pins on the microcontroller, and (c) the bottom pin on the right side of the L293D connects to the microcontroller voltage instead of the motor power voltage.

(As in the previous schematic, the control pin numbers #1 and #2 are just a convention for this drawing and you can substitute with any digital pins on your microcontroller.)

I think it’s kind of weird that microcontroller voltage is supplied through three pins but the voltage that powers both motors is supplied through just one pin. Since the motors draw a lot more current than the microcontroller, it seems like the power voltage should have more pins. ‘More pins for more current’ seems intuitive. But I think the fact that it’s the other way in reality has something to do with the microcontroller voltage being a reference voltage. If you know the true answer, please leave a comment.

Since the OWI-535 has five motors and since each L293D chip can control two motors, it would seem that I only need three chips and I’m good to go. Yay! That’s what I thought last week, and so I went to the local electronics store and bought three L293D chips. Then I took a closer look at the specs for the chip, and recognized that the motor supply voltage has a requirement to be above 4.5 volts.

This creates a problem for me in that the OWI-535 motors appear to be rated for a maximum voltage of only 3 volts. I don’t want to burn out the motors, so the L293D is not the right chip for my project.

However, Good Reader, if you’re working on a project where the motors run at above 4.5 volts, the L293D could be the motor controller chip that’s right for you.

The L293D datasheet links here.


The L9110 motor controller chip

Is there a motor-control chip for those of us with DC motors that operate in the <= 3v range? Yes! It’s called the L9110 (which I pronounce “L Ninety-One Ten”).

For low-voltage DC motors, the L9110 appears to be the chip of choice. However, unlike the L293D, the L9110 serves to replace only one H-bridge.

I’ve ordered some L9110 chips online and they’re on their way. My next blog post will be about the L9110 and my experiences connecting the L9110s to the DC motors of my OWI-535 robot arm.


What’s Next?

The OWI-535 isn’t programmable because there are no arm-segment position tracking mechanisms — that is, other than the user’s eyeballs. I don’t intend to make position tracking mechanisms for the arm at this time. This is acceptable for my purposes in that I intend to experiment with the robot arm in ‘human mode’ — first with more user-friendly interfaces and eventually to control the arm over the internet.

Comments and corrections are welcome, and please subscribe to my blog if you want to keep track of my progress.

Posted in Uncategorized | Tagged , , | Leave a comment

OWI-535 Robotic Arm Edge Assembly Tips

The OWI robotic arm has over 1100 reviews on Amazon already, so I won’t review it here. Instead, I wanted to share some tips that I learned while assembling the robot. It took me five hours — but maybe with the help of these tips, you can do it much faster!

If I can finish it, anyone can!

Get a good screwdriver

There are sixty-four tiny screws in the OWI-535 kit. Holding the screwdriver, the screw, and the two parts to be attached sometimes feels like a job that requires four hands. A magnetic screwdriver will hold onto the screw and help you position it over the hole, which makes the task a lot easier.

Actually, I don’t know if the screws in the kit are attracted by magnets, but it certainly would have sped things up quite a bit if they were and if my screwdriver had been magnetic.

Also, I was using a tiny screwdriver I got from a dollar store, and that wasn’t great either. A screwdriver should have a comfortable size to fit in your hand if you’re going to be using it a lot.

Another thing you might consider is a battery powered screw driver. This will relieve a lot of the tedium and wrist/finger strain. If you do a lot of kit assembly, it’s a good investment.


Use a glue stick to hold the nuts in place

Assembly and Instruction Manual

There are five motor cases in the OWI-535 kit, and they each have four screws and four nuts to attach them to the rest of the arm assembly. That’s twenty of these tiny little nuts that must be inserted in the casing slots (as shown).

Problem is, once you insert the nuts and close up the case, they have a tendency to fall out of place. This is very discouraging because you’ll need to re-open the case, and when you do that, the gears and motor will shift around and thus also need to be re-positioned. Then you close the case and . . . same thing over and over.

However, I found that if I rubbed a glue stick onto the nuts, the glue would keep the nuts in place long enough to fasten the bolts. We’re not talking superglue here, just a regular old glue stick. I wasted an hour on positioning and repositioning the nuts in just the first case before I learned this trick, and I doubt that I would have been able to finish the entire assembly at all without doing this.


Pay attention to how the parts are positioned according to the manual

The above illustration in the OWI-535 assembly instructions pamphlet shows that the two claws of the gripper need to be spread apart an equal distance so that they will come together in the center. So I thought, why not assemble them so that they are already touching in the middle? Well, if you do that, you won’t be able to install the light that goes between them.

(You may notice from the photo that I didn’t get around to installing the light or the hood on the gripper, btw.)

A similar issue happened when I didn’t have the arm in the same pose as the illustration in the assembly instructions, and that created problems in being able to fit parts together.

The instructions don’t specifically tell you that you must assemble the arm in the poses shown in the illustrations, but it’s a good idea.


Random Meta Stuff

You might be thinking, “Why not just get a servo arm and forget all this business of gears and complex wiring?” Well, that works with big servos, but those robot arms are more expensive. As for the 9g micro-servos, I’m not so sure they have enough power to lift even themselves. I may be wrong on that, but I did assemble a micro-servo arm before this and the motor action was woefully feeble. So there’s a reason this kit is so popular.

It helps to know the big picture so that you don’t get discouraged somewhere in the middle. So just what are you doing? You’re putting five motors in cases with gears that trade off rotational speed for torque. Then you’re attaching the motor cases so that one motor each operates the gripper, the wrist, the elbow, the base up-and-down, and the base rotation. Then you’re connecting the battery and the wires of the motors to the control box. Finally, you assemble the levers and electrical contacts of the control box. And you’re done!

And everything is held together by screws. Lots of screws.

Highly recommended that you read the instructions at least once. The more you know what you’re doing, the more confidence you ‘ll have, and the faster you’ll get it done with fewer errors.

Well, I hope this helps and that you are able to avoid frustration and have fun while assembling your OWI-535 “Edge” arm — and I especially hope that it works!

If you have any tips of your own, please leave a comment. Thanks!

As for me, in the near future I intend to hack the arm to put it under the control of an arduino. If that sounds interesting, I hope you’ll check back.

Posted in robotics | Tagged , , | 1 Comment

Nooli Dots

I wrote a memory match game app. It’s free with no ads or in-app purchases on Google Play. Here’s the link:

Nooli Dots

Posted in Uncategorized | Tagged , , | Leave a comment

Timesense, a science fiction novella

Free July 7-8 on Amazon Kindle:


For millennia the starship voyaged from Sirius to Sol. It seemed as dead as any sterile asteroid drifting between the light years. Nothing moved within the frames of its unlit portals. Aside from the feeble reflection of starlight, the ship emitted no discernible electromagnetic radiation. The square kilometers of its solar sails were limp and the sail control threads were slack.

At one end of the fifty meter ovoid that was the ship’s body were the winches that manipulated the sail threads. Beneath the winch platform was the ship’s bridge. Like the rest of the ship, its interior was dark and still.

Prominently featured on the circular bulkhead of the bridge was a temperature gage, its needle pointing a sliver past absolute zero. The gage next to it indicated a cabin pressure of zero.

Floating in harnesses among the tables of levers and gages were the members of the crew. They were meter-tall figurines made of rock. Their lower bodies were like six-legged spiders. Their upper bodies were cone shaped and had four squid-like tentacles for arms. Each face was a pair of eye stalks above a toothless mouth and beneath an antenna mast.

The crewbeings were as unmoving as the rest of the ship. The last time they had moved, the Pyramids of Giza were still under construction. But after dreamlessly sleeping through almost all of human history, it was their time to awaken.

Timesense on Amazon Kindle

Posted in Uncategorized | 2 Comments

The Ten Million Ton Space Elevator

Carbon nanotubes are often assumed to be the sole viable material for the construction of an Earth-based space elevator. However, carbon nanotubes in the lengths required for construction of a space elevator remain a laboratory curiosity. Is there an alternative to carbon nanotubes for building a space elevator?


The next strongest material is zylon. Zylon is a polymer chain of carbon and other atoms. It has a breaking length of 384 kilomometers, fifty percent greater than kevlar. Zylon also has an advantage over carbon nanotubes in that it is being currently produced in mass quantities at relatively low cost.

Unfortunately, when we plug the numbers for zylon into the basic space elevator equation, we get a taper ratio of a million to one. That means we’ll need at least ten million ton space elevator cable to lift a ten ton cable crawler. A mass of ten million tons would seem to rule out zylon as a space elevator construction material.

Nonetheless, if we’re going to put people into space, a space elevator is safer and cheaper than rockets, and even a ten million ton space elevator is better than none at all. So let’s look at three methods of moving large amounts of material in space and how they can be repurposed for provisioning a zylon space elevator.

Method #1: The Space Gun

Orbital space factories would operate in conditions of zero gravity and high vacuum. The manufacture of many products, such as fiber optics and microelectronics, could benefit from such conditions. But how do we supply the orbital factories with raw materials? If we use conventional rockets, the high launch cost will make space-based manufacturing unprofitable.


US military space gun. The technology is so off the shelf that it’s begun to corrode!

An electromagnetic ‘rail gun’ could change that. Built on the slopes of a mountain near the equator, the rail gun — or rather, ‘space gun’ — could accelerate payloads up to a muzzle velocity sufficient to achieve orbit. Once the capital cost of construction is absorbed, the cost of shooting payloads into orbit would be only the cost of the electricity. Once in orbit, the payloads of raw materials would be retrieved by robots and processed in factories. The finished products would be packed inside inexpensive ceramic re-entry shields for a soft landing in the ocean for retrieval.

An earth-based space gun could not be used to put humans into space. Even if it were several kilometers long, it would need to accelerate payloads at thousands of gees in order to reach the required velocity. This is a force that would easily squash humans.

A space gun could, however, be used to launch payloads of zylon cable that will be used to build a space elevator. If — when — space manufacturing takes off, the space gun may eventually have a launch capacity big enough to supply the required amount of zylon in just a few years of operation.

Method #2: Lunar Mining

As we continue to scour the surface of the Earth for metals, we are starting to consider mining metals and minerals from the Moon as well. Teleoperated robots on the Moon could prospect and mine for gold, platinum, palladium and other rare metals. This material could be sent back to Earth by utilizing a lunar space elevator. At the high tip of the elevator, we would then drop the payloads into Earth’s gravity well. Again we would use inexpensive ceramic shells for friction braking in Earth’s atmosphere and retrieval in the ocean.


NASA image shows astronauts on the Moon, but it would be more economical to send robots ahead to mine the Moon and build the colony.

Thanks to the Moon’s lower gravity, a lunar space elevator would be much shorter than an Earth-based space elevator and require no taper at all. A starter lunar elevator could be packed inside a single rocket payload. As lunar mining operations grow, the lunar elevator’s lift capacity can be increased with the use of zylon cable fabricated on the Moon from materials taken from the Moon.

With a big enough lunar elevator, we could consider mining the Moon for not-so-rare metals like lithium and silver. Once the lunar space elevator’s lift capacity is increased to hundreds of thousands of tons annually, we can use lunar resources to fabricate our ten million ton Earth-based space elevator.

Method #3: Asteroid Capture

Asteroids with diameters measured in tens of meters cross the orbit of the Earth every year. It’s statistically inevitable that one of them will impact our planet, and given the increasingly dense population of the Earth, a city could be struck with the kinetic energy release of an atomic bomb. Being able to protect ourselves from asteroid impact is seen by many people as a key priority for national and international space programs.


Mini asteroids are constantly wandering between Earth and lunar orbit. We don’t have to go far to capture one.

We need the technology to protect ourselves from asteroid impact. We need to develop robots and space tugs that can intercept asteroids and divert them from their paths. And before we can do the real thing, we need to practice. We need to use robots and space tugs to intercept and capture a mini-asteroid and put it in orbit.

Even these very small asteroids can easily weigh a million tons or more. Catch a few of them, and you’ve got enough material to build a zylon space elevator.

Seeing the Big Space Elevator Picture

As the Earth becomes increasingly overpopulated, global pollution and wars over resources threaten the survival of the human species. A viable system of space elevators could offer space colonization as an alternative to rationing, regimentation, and global conflict.


Space colonies have been considered by NASA for decades, but we’ll need a revolutionary space transportation system for people to colonize space.

Space elevators offer a way to economically transport large numbers of people from Earth to colonies in space. Building space elevators that mass in the millions of tons each would be a tremendous engineering challenge, but the cost would be far less having to rebuild civilization after a global thermonuclear war fought over resources and territory.

We can launch the zylon cable from Earth with space guns, from the Moon with a lunar space elevator, or we can mine the material from captured asteroids. With zylon as the construction material for space elevators, we presently have the technology to affordably colonize other worlds in space.

Posted in space technology, Uncategorized | Tagged , , , | Leave a comment

Graph of IQ vs. US Household Income Percentiles

graph (1)

Here’s a graph that I made of IQ vs. US Household Income percentiles.  In other words, I looked up the percentiles for IQ and cross-referenced them with the percentiles for US Household Income.

Of course, financial status is a function of many factors such as intelligence, luck, hard work, and life choices.  Perhaps the value of this graph is in indicating how much financial status is affected by those other factors.

References are IQ Comparison Chart and United States Household Income Brackets and Percentiles in 2017.  I made this graph by using Create a Graph.

(And to promote my science fiction novel:  The Wizard from Earth.)

Posted in Uncategorized | Leave a comment

Structures: Or Why Elon Musk Recommends This Book


Elon Musk has provided us with a list of fourteen favorite books that inspired him, and amid fantasy novels such as Lord of the Rings and Hitchhiker’s Guide to the Galaxy and biographies of Benjamin Franklin and Albert Einstein is a book on material science entitled, Structures: Or Why Things Don’t Fall Down.

Structures was published in 1978 and was written by J.E. Gordon, a British material scientist. In the forward, Gordon refers to the book as, “. . . an elementary book about structures . . . stripped of its mathematics.”

Structures was one of only two books on Musk’s list that could be termed ‘technical,’ which caused me to think I should read it. And I wasn’t the only one who came to that conclusion. There were over two dozen holds on the single copy in the local library system, and I had to wait over a year to get my hands on it.

So why did Elon Musk recommend an obscure popular science book?  Given that the book is almost forty years old, is it still relevant and useful to today’s engineers? I’ll provide a brief overview here so that you can decide for yourself.

All Structures, Great and Small

As the complete title is, Structures: or why things don’t fall down, you might think that the book is specifically about buildings and bridges. Author J. E. Gordon, however, simply describes a structure as, “Any assemblage of materials which is intended to sustain loads,” and thus the book covers a broad range of subjects whose only connection is the application of the basic structural concepts of stress and strain.

For example, Gordon discusses design and operation of archery bows, why chariots had their wheels removed when they weren’t in use (because they tended to deform under loads), and the history of catapults — such as a Roman admiral who won a battle by hurling pots filled with snakes (which doesn’t have much to do with material science but makes an interesting anecdote).

Even farther from buildings and bridges, Gordon spends a fair portion of the book discussing structure in animals and plants. “Nature having invented life . . . it became necessary to devise some kind of container in which to keep it.” So he starts with the structure of the cell, and goes on to skeletons, and why plants are often better armored than animals (weight of armor affects mobility) and why birds have feathers (they give the wing a better lifting shape without adding excessively to weight).

The book also discusses the roles of the Poisson Ratio and Wagner tension field (which he explains) in dress design, how to keep boilers from exploding, and how to keep wings from twisting off airplanes (and how trying to keep wings from twisting off airplanes can cause even more wings to twist off airplanes).

While some of this discussion is technical, there are also poignant stories, like the tragic tale of the H.M.S. Captain, a nineteenth century combination sail and steam ship that was designed by a naval captain to his personal specifications after a massive publicity campaign, and which promptly sank in a mild squall with the loss of 472 lives and only seventeen survivors (the designer-captain having gone down with his ship).  Gordon writes that due to ‘muddling,’ the ship was about 15 percent overweight.  “If this had not been the case it is at least possible that the ship would have been a success and comparatively safe.”

But yes, in accord with the title, a lot of the book is about structures, and specifically, why those structures don’t fall down. So you learn about tensile strength (hanging cables) and compression (stacking things). And it turns out a lot of civil engineering isn’t intuitively obvious. For example, masonry buildings have enough compression strength to be built much taller than they were in ancient times, but stability problems arose. And why don’t cathedral arches collapse? Because of the statues on the sides. Really. Seriously. Who knew?

The Structure of Structures

Despite the assertion in the forward, there is a bit of mathematics sprinkled throughout the book. Not as much as there would be in a college textbook, but some of the algebraic formulas would keep you busy at a calculator for a few minutes if you didn’t let your eyes glaze over them (like I did). For the most part, they don’t get in the way of casual reading.

And for the most part, the book is fairly light reading. It’s written in a humorous style, which you can see from the chapter titles. Here’s a couple: Chapter 5: “Strain energy and modern fracture mechanics — with a digression on bows, catapults and kangaroos.” Chapter 12: “The mysteries of shear and torsion — or Polaris and the bias-cut nightie.”

Gordon also avoids dryness by focusing on the human drama behind engineering, relating how Robert Hooke, who originated Hooke’s Law (Strain is proportional to stress), was a ‘lady’s man’ disdained by Isaac Newton for dirtying the noble pursuit of science with the shabbiness of practical application, and how Galileo, forced by the Church to recant his discoveries in astronomy, spent his days under house arrest investigating the science of structures, “ . . . as being, I suppose,” Gordon writes, “the safest and least subversive subject he could think of.”

Philosophically, Gordon stresses a number of themes, and one of the key ones is to contrast theory versus experience. He is fair to both sides. He notes that nineteenth century engineers who knew little theory built bridges that stand today, while modern bridges could not be built without rigorous mathematical analysis. Even then, mathematical analysis is insufficient to identify local discontinuities that can lead to crack propagation and structural failure. (Although in the time since the book was written, computer simulations may have gotten good enough to address this concern.)

The Book and Elon

So why would Elon Musk recommend this book above the countless other books that he’s read? Perhaps one answer is that the book was published and enjoyed its heyday at the time when he was a kid. We tend to best remember books from our youth, and because we’re impressionable at that age, we naturally are more impressed by books we read then than at later stages in our lives.  But I think there’s more to it than that.

In researching this article, I came across an interview in which Musk is asked what he would do to fix the traffic problem on an LA freeway. He suggests double-decking the existing road with prefabricated sections, and the interviewer asks, “Would that appeal to your sense of aesthetics?” and Musk quickly replies, “We would make it look nice.” This sensitivity to aesthetics is also apparent in the design of Tesla cars and the Dragon capsule and is right out of the last chapter of Structures, where Gordon laments the loss of aesthetics in the pursuit of efficiency: “Is it not fair to ask the technologist, not only to provide artefacts which work, but also to provide beauty, even in the common street, and, above all, to provide fun?”  This view of aesthetics as both important and fun clearly influences Musk’s design philosophy, and it has been a successful business strategy for him.

But also, there’s a lot in Structures that has practical application to what Musk is doing with SpaceX and the Falcon rockets. In many ways, rockets are like buildings — buildings as tall as skyscrapers, that must be able to endure gravitational stresses many times higher than normal and vibrations greater than most earthquakes, that despite the need for immense structural strength must be made as light as possible or they won’t be able to do their primary function, which is to fly faster and farther than any vehicle ever made. Gordon devotes only a few words in Structures to rockets, but if you’re aware of the engineering considerations relevant to all structures, you will be aware during reading of how much of the book is critically relevant to rocketry.

Structures: Or Why Things Don’t Fall Down may have waned in popularity over the years, but thanks to Musk’s recommendation it is enjoying a revival and is a currently a bestseller on Amazon. The ninety-three reviews (at current count) rate it between four and five stars. So Elon Musk isn’t the only person who finds this book worthwhile. I think you will too.

Posted in book review | Tagged , , , , , | 1 Comment