When you acquired your first oscilloscope, what were the first waveforms you had a look at with it? The calibration output, and maybe your signal generator. Then if you are like me, you probably went hunting round your bench to find a more interesting waveform or two. In my case that led me to a TV tuner and IF strip, and my first glimpse of a video signal.
An analogue video signal may be something that is a little less ubiquitous in these days of LCD screens and HDMI connectors, but it remains a fascinating subject and one whose intricacies are still worthwhile knowing. Perhaps your desktop computer no longer drives a composite monitor, but a video signal is still a handy way to add a display to many low-powered microcontroller boards. When you see Arduinos and ESP8266s producing colour composite video on hardware never intended for the purpose you may begin to understand why an in-depth knowledge of a video waveform can be useful to have.
The purpose of a video signal is to both convey the picture information in the form of luminiance and chrominance (light & dark, and colour), and all the information required to keep the display in complete synchronisation with the source. It must do this with accurate and consistent timing, and because it is a technology with roots in the early 20th century all the information it contains must be retrievable with the consumer electronic components of that time.
We’ll now take a look at the waveform and in particular its timing in detail, and try to convey some of its ways. You will be aware that there are different TV systems such as PAL and NTSC which each have their own tightly-defined timings, however for most of this article we will be treating all systems as more-or-less identical because they work in a sufficiently similar manner.
Humans are very good at watching others and imitating what they do. Show someone a video of flipping a switch to turn on a CNC machine and after a single viewing they’ll be able to do it themselves. But can a robot do the same?
Bear in mind that we want the demonstration video to be of a human arm and hand flipping the switch. When the robot does it, the camera that is its eye will be seeing its robot arm and gripper. So somehow it’ll have to know that its robot parts are equivalent to the human parts in the demonstration video. Oh, and the switch in the demonstration video may be a different model and make, and the CNC machine may be a different one, though we’ll at least put the robot within reach of its switch.
Researchers from Google Brain and the University of Southern California have done it. In their paper describing how, they talk about a few different experiments but we’ll focus on just one, getting a robot to imitate pouring a liquid from a container into a cup.
Do you remember your first instrument, the first device you used to measure something? Perhaps it was a ruler at primary school, and you were taught to see distance in terms of centimetres or inches. Before too long you learned that these units are only useful for the roughest of jobs, and graduated to millimetres, or sixteenths of an inch. Eventually as you grew older you would have been introduced to the Vernier caliper and the micrometer screw gauge, and suddenly fractions of a millimetre, or thousandths of an inch became your currency. There is a seduction to measurement, something that draws you in until it becomes an obsession.
Every field has its obsessives, and maybe there are bakers seeking the perfect cup of flour somewhere out there, but those in our community will probably focus on quantities like time and frequency. You will know them by their benches surrounded by frequency standards and atomic clocks, and their constant talk of parts per billion, and of calibration. I can speak with authority on this matter, for I used to be one of them in a small way; I am a reformed frequency standard nut. Continue reading “Confessions Of A Reformed Frequency Standard Nut”→
As hackers, we like to think of ourselves as a logical bunch. But the truth is, we are as subject to fads as the general public. There was a time when the cool projects swapped green LEDs out for blue ones or added WiFi connectivity where nobody else had it. Now all the rage is to connect your project to a personal assistant. The problem is, this requires software. Software that lives on a publicly accessible network somewhere, and who wants to deal with that when you’re just playing with custom Alexa skills for the first time?
If you have a computer that faces the Internet, that’s fine. If you don’t, you can borrow one of Amazon’s, but then you need to understand their infrastructure which is a job all by itself. However, there is a very simple way to jump start an Alexa skill. I got one up and running in virtually no time using a website called Glitch. Glitch is a little bit of everything. It is a web hosting service, a programming IDE for Node.js, a code repository, and a few other things. The site is from the company that brought us Trello and helped to start Stack Overflow.
Glitch isn’t about making Alexa skills. It is about creating web applications and services easily. However, that’s about 90% of the work involved in making an Alexa skill. You’ll need an account on Glitch and an Amazon developer’s account. Both are free, at least for what we want to accomplish. Glitch has some templates for Google Home, as well. I have both but decided to focus on Alexa, for no particular reason.
I’ve got a friend who tells me at every opportunity that soy is the downfall of humanity. Whatever ails us as a society, it’s the soy beans that did it. They increase violent tendencies, they make us fat and lazy, they run farmers out of business, and so on. He laments at how hard it is to find food that doesn’t include soy in some capacity, and for a while was resigned to eating nothing but chicken hot dogs and bags of frozen peas; anything else had unacceptable levels of the “Devil’s Bean”. Overall he’s a really great guy, kind of person who could fix anything with a roll of duct tape and a trip to the scrap pile, but you might think twice if he invites you over for dinner.
So when he recently told me about all the trouble people are having with soy-based electrical wiring, I thought it was just the latest conspiracy theory to join his usual stories. I told him it didn’t make any sense, there’s no way somebody managed to develop a reliable soy-derived conductor. “No, no,” he says, “not the conductor. They are making the insulation out of soy, and animals are chewing through it.”
Now that’s a bit different. I was already well aware of the growing popularity of bioplastics: the PLA used in desktop 3D printers is one such example, generally derived from corn. It certainly wasn’t unreasonable to think somebody had tried to make “green” electrical wiring by using a bioplastic insulation. While I wasn’t about to sit down to a hot bag of peas for dinner, I had to admit that maybe in this case his claims deserved a look.
Here on Hackaday, we’re generally designers of hacks that live in the real world. Nevertheless, I’m convinced that some of the most interesting feats are at the mercy of what’s possible in software, not hardware. Without the right software, no 3D printer could print and no quadcopter could fly. The source code that drives these machines may take months of refinement to flesh out their structure. In a nutshell, these software packages are complicated, and they don’t happen overnight.
So how do they happen; better yet: how could we make that happen? How do we write software that’s flexible enough to coexist peacefully on all sorts of hardware variations?
What separates the big open-source software projects like ROS, LinuxCNC, and Multiwii from the occastional hackathon code are the underlying principles that govern how they’re written. In object-oriented programming, these principles are called design patterns. In the next couple posts, I’m going to crack the lid on a few of these. What’s more, I’ll package them into real-world examples so that we can see these patterns interact with real hardware. The next time you pop open the source code for a big open source hardware project, I hope you can tease out some of these patterns in the code. Better yet, I hope you carry these patterns into your next robot and machine project. Let’s get started.
For readability, all of the examples run in Python3. The snippets below are truncated for brevity, but the real examples in the repository will work if you’ve got a similar hardware setup.
About two months ago I rode my bike to work like any other day, but on the way home a construction project seemed to have spontaneously started at one of the bridges that I pass over. Three lanes had merged into one which, for a federal highway, seemed like a poorly planned traffic pattern for a such a major construction project. As it happens, about an hour after I biked across this bridge that morning both outside sections of the bridge fell into the water. There was no other physical damage that seemed to explain why parts of a bridge on U.S. 1 would suddenly collapse.
The intriguing thing about this bridge collapse was that the outer retaining wall and about half of the sidewalk on both the northbound side and the southbound side had fallen into the water at the same time. This likely wasn’t caused by something like a boat impact, car accident, or an overweight truck. Indeed, Florida Department of Transportation (FDOT) investigated the incident and found that two post tension wires that held these sections of the bridge together had failed, making it unsafe for pedestrians and bicyclists but also for any boaters below. Continue reading “Local Infrastructure: The Devil is in the Details”→