Hackaday’s finest original content articles curated by the Hackaday editors
I am always torn about the title of “engineer.” When I talk to school kids about engineering, I tell that an engineer is a person who uses science and math to solve or analyze practical problems. However, these days you hear a lot of engineering titles thrown around to anyone who does any sort of technical (and sometimes non-technical) work. “Software engineers” don’t have to be licensed to practice, while civil engineers do. What’s in a name and does any of this matter?
When a consumer electronics device is sold in the US, especially if it has a wireless aspect, it must be tested for compliance with FCC regulations and the test results filed with the FCC (see preparing your product for FCC testing). These documents are then made available online for all to see in the Office of Engineering and Technology (OET) Laboratory Equipment Authorization System (EAS). In fact, it’s this publishing in this and other FCC databases that has led to many leaks about new product releases, some of which we’ve covered, and others we’ve been privileged enough to know about before the filings but whose breaking was forced when the documents were filed, like the Raspberry Pi 3. It turns out that there are a lot of useful things that can be accomplished by poring over FCC filings, and we’ll explore some of them.
At my university, we were all forced to take a class called Engineering 101. Weirdly, we could take it at any point in our careers at the school. So I put it off for more interesting classes until I was forced to take it in one of my final years. It was a mess of a class and never quite seemed to build up to a theme or a message. However, every third class or so they’d dredge up a veritable fossil from their ranks of graduates. These greybeards would sit at the front of the class and tell us about incredible things. It was worth the other two days of nondescript rambling by whichever engineering professor drew the short straw for one of their TAs.
One greybeard in particular had a long career in America’s unending string of, “Build cool stuff to help us make bad guys more deader,” projects. He worked on stealth boats, airplanes with wings that flex, and all sorts of incredibly cool stuff. I forgot about the details of those, but the one that stuck with me was the Cyclocrane. It had a ton of issues, and as the final verdict from a DARPA higher-up with a military rank was that it, “looked dumb as shit” (or so the greybeard informed us).
The Cyclocrane was a hybrid airship. Part aerodynamic and part aerostatic, or more simply put, a big balloon with an airplane glued on. Airships are great because they have a constant static lift, in nearly all cases this is buoyancy from a gas that is lighter than air. The ship doesn’t “weigh” anything, so the only energy that needs to be expended is the energy needed to move it through the air to wherever it needs to go. Airplanes are also great, but need to spend fuel to lift themselves off the ground as well as point in the right direction. Helicopters are cool because they make so much noise that the earth can’t stand to be near them, providing lift. Now, there’s a huge list of pros and cons for each and there’s certainly a reason we use airplanes and not dirigibles for most tasks. The Cyclocrane was designed to fit an interesting use case somewhere in the middle.
In the logging industry they often use helicopters to lift machinery in and out of remote areas. However, lifting two tons with a helicopter is not the most efficient way to go about it. Airplanes are way more efficient but there’s an obvious problem with that. They only reach their peak efficiency at the speed and direction for which their various aerodynamic surfaces have been tuned. Also worth noting that they’re fairly bad at hovering. It’s really hard to lift a basket of chainsaws out of the woods safely when the vehicle doing it is moving at 120mph.
The cyclocrane wanted all the efficiency of a dirigible with the maneuverability of a helicopter. It wanted to be able to use the effective lifting design of an airplane wing too. It wanted to have and eat three cakes. It nearly did.
Four wings stick out of a rotating balloon. The balloon provides half of the aerostatic lift needed to hold the plane and the cargo up in the air. The weight is tied to the static ends of the balloon and hang via cables below the construction. The clever part is the four equidistant wings sticking out at right angles from the center of the ship. At the tip of each wing is a construction made up of a propellor and a second wing. Using this array of aerofoils and engines it was possible for the cyclocrane to spin its core at 13 revolutions per minute. This produced an airspeed of 60 mph for the wings. Which resulted in a ton of lift when the wings were angled back and forth in a cyclical pattern. All the while, the ship remaining perfectly stationary.
Now the ship had lots of problems. It was too heavy. It needed bigger engines. It was slow. It looked goofy. It didn’t like strong winds. The biggest problem was a lack of funding. It’s possible that the cyclocrane could have changed a few industries if its designers had been able to keep testing it. In the end it had a mere seven hours of flying time logged with its only commercial contract before the money was gone.
However! There may be some opportunity for hackers here. If you want to make the quadcopter nerds feel a slight sting of jealousy, a cyclocrane is the project for you. A heavy lift robot that’s potentially more efficient than a balloon with fans on it is pretty neat. There’s a bit of reverse engineering to be done before a true performance statement can be made. If nothing else. It’s just a cool piece of aerospace history that reminds us of the comforting fact that we haven’t even come close to inventing it all yet.
If you’d like to learn more there’s a ton of information and pictures on one of the engineer’s website. Naturally wikipedia has a bit to say. There’s also decent documentary on youtube, viewable below.
Photo Credits: Rob Crimmins and Hal Denison
Meetings can actually be useful. It’s hard to believe, but they can actually save time if done right. While most of us are in a perpetual state of torture by Kevin in marketing holding another three-hour meeting during lunch hours, there are a few of us who know their hidden power when put in the right hands.
Working as a contractor, wasted meetings mean wasted billable hours. Even wasted meeting time is covered in the cost of the contract it runs the risk of giving the client the impression that you’re not as productive as originally thought. Organized, productive meetings show that you know what you’re doing and that the cost of your services as a whole is a good value. Yeah, some meetings suck but they are necessary and should be productive.
A meeting needs three things to be worth the time spent on it.
I’ll start with the third item as it shapes the rest. The point of a meeting is to have something to write down at the end of the meeting. Any meeting that ends up in anything requiring fallible human memory was a waste of everyone’s time. This includes, verbal agreements, handshake agreements, ideating (pronounced idioting), brainstorming, think tanking, and the like.
A few weeks back, we got a taste for two-stage tentacle mechanisms. It’s a look at how to make a seemily complicated mechanism a lot less mysterious. This week, we’ll take a close look at one (of many) methods for puppeteering these beasts by hand. Best of all, it’s a method you can assemble at home!
Without a control scheme, our homebrew tentacle can only “squirm around” about as much as an overcooked noodle. It’s pretty useless without some sort of control mechanism to keep all the cables in check at proper tension. Since the tentacle’s motion is driven by nothing more than four cable pairs, it’s not too difficult to start imagining a few hobby servos and pulleys doing the job. To get us started, though, I’ve opted for hand controllers just like the puppeteers of the film industry.
Hand controllers? Of all the possibilities offered by electronics, why select such an electronics-devoid caveman approach? Fear not. Hand controllers offer us a unique set of opportunities that aren’t easy to achieve with most alternatives.
Continue reading “Two-Stage Tentacle Mechanisms Part II: The Cable Controller”
A few weeks ago I asked the Hackaday community for some help and advice in buying a new budget oscilloscope. Thank you very much to those of you who responded both here online and in person among my friends closer to home. I followed the overwhelming trend in the advice I received, and bought myself a Rigol DS1054z, an instrument with which I am very happy. It’s a nominally a 50 MHz scope, but there’s a software hack that can bring it up to 100 MHz. How fast can it go?
This question became a mini scope-shootout after a conversation with my Hackaday colleague [Elliot] about measuring oscilloscope bandwidth, and then my fellow Oxford Hackspace members producing more than one scope for comparison. You know who you are, thank you. I found myself with ready access to several roughly equivalent models and one very high-end one in specification terms representing different strata of test equipment manufacture, and with the means to examine their performance.
The abundance of small networked boards running Linux — like the Raspberry Pi — is a boon for developers. It is easy enough to put a small cheap computer on the network. The fact that Linux has a lot of software is a double-edged sword. On the one hand, it is a good bet that anything you want to do has been done. On the other hand, some of the solutions are a bit large for a tiny embedded system.
Take, for example, e-mail. Historically, Linux hosts operate as mail transfer agents that can send and receive mail for all their users and possibly even relay mail to others. In today’s world, that’s usually overkill, but the capability is there. It is possible to install big mail transfer agents into a Raspberry Pi. The question is: should you?
The answer, of course, depends on what you want to do. If you have a dedicated board sending out text and maybe even files using an external mail server (like, say, Gmail), then the answer is no. You don’t need a piece of software listening for incoming connections, sorting through multiple users, and so on.
Luckily, there are some simple solutions if you know how to set up and configure them. The key is to avoid the big mail programs that do everything you don’t need.
Let’s tackle sending mail first. If you try to grab the mailutils package, you’ll see it drags along a lot of stuff including mysql. Keep in mind, none of this will actually send mail. It just gives you some tools to get mail ready to send.
Luckily, the bsd-mailx package has a lot less overhead and will do the job. Look at the man page to see what options you have with mailx; you can do things like attach files, set a subject, and specify addresses.
It is a little difficult to set up for Gmail, though, thanks to Google’s security. You’ll need the certutil tool from the libnss3-tools package. You’ll need to create a certificate store, import Google’s certificate, and then set up a lot of options to mailx. I don’t suggest it. If you insist, though, you can find directions on the Web.
By default, programs like mailx and other Linux mail commands rely on a backend (often sendmail). Not only does that drag around too much overhead, it is also a full mail system, sending and receiving and relaying–overkill for our little Pi computers.
Luckily, SSMTP is available which only sends mail and is relatively lightweight. You need a configuration file to point it to your mail server. For Gmail, it would look like this:
# # Config file for sSMTP sendmail # # The person who gets all mail for userids < 1000 # Make this empty to disable rewriting. root=postmaster # The place where the mail goes. The actual machine name is required no # MX records are consulted. Commonly mailhosts are named mail.domain.com mailhub=smtp.gmail.com:587 # Where will the mail seem to come from? rewriteDomain=yourdomain.com # The full hostname hostname=yourhostname AuthUser=YourGmailUserID AuthPass=YourGmailPassword UseTLS=Yes UseSTARTTLS=YES # Are users allowed to set their own From: address? # YES - Allow the user to specify their own From: address # NO - Use the system generated From: address FromLineOverride=YES
You can use a mail agent like mailx or you can just use ssmtp directly:
ssmtp someone@somewhere.com
Enter a message on the standard input and end it with a Control+D (standard end of file for Linux).
There’s only one catch. If you are using Gmail, you’ll find that Google wants you to use stronger authentication. If you are using two-factor (that is, Google Authenticator), this isn’t going to work at all. You’ll need to generate an app password. Even if you aren’t, you will probably need to relax Google’s fear of spammers on your account. You need to turn on the “Access for less secure apps” setting. If you don’t want to do this on your primary e-mail account, considering making an account that you only use for sending data from the Pi.
Depending on the mail software you use, there are a few ways you can attach a file. However, the mpack program makes it very easy:
mpack -a -s 'Data File' datafile.csv me@hackaday.com
The above command will send datafile.csv as an attachment with the subject “Data File.” Pretty simple.
What if you want to reverse the process and receive mail on the Pi? There is a program called fetchmail that can grab e-mails from an IMAP or POP3 server. It is possible to make it only read the first unread message and send it to a script or program of your choosing.
You have to build a configuration file (or use the fetchmailconf program to build it). For example, here’s a simple .fetchmailrc file:
poll imap.gmail.com protocol IMAP user "user@gmail.com" with password "yourpassword" mda "/home/pi/mailscript.sh" folder 'INBOX' fetchlimit 1 keep ssl
You can leave the “keep” line out if you don’t mind fetchmail deleting the mail after processing. The file should be in your home directory (unless you specify with the -f option) and it needs to not be readable and writable by other users (e.g., chmod 600 .fetchmailrc). According to the fetchmail FAQ, there are some issues with Gmail, so you might want to consider some of the suggestions provided. However, for simple tasks like this, you should be able to work it all out.
In particular, the mailscript.sh file is where you can process the e-mail. You might, for example, look for certain keyword commands and take some action (perhaps replying using ssmtp).
You might not think of the Raspberry Pi as an e-mail machine. However, the fact that it is a pretty vanilla Linux setup means you can use all sorts of interesting tools meant for bigger computers. You just have to know they exist.
