Machinists like to live on the edge, but they always want to know precisely where it is. If you’ve watched any machining videos (*cough*) then you’ve seen heavy use of digital readouts on machines. A “DRO” (as the cool kids call them) is a little computer that knows where the slides are, and thus where your cutter is on the piece. However, there’s a catch. DROs don’t know the absolute position of the spindle, they know the relative position of it. The bottom line is that a DRO is just a fancier version of the graduated scales on the hand wheels. The key difference is that the DRO doesn’t suffer from backlash, because it is measuring the slides directly (via glass scales similar to your digital caliper) rather than inferring position from rotations of the leadscrews. With traditional hand wheels, you have to compensate for backlash every time you change direction, and a DRO saves you from that (among other convenience features).
The point is that, whether old school or new, you still only get a relative coordinate system on your part. You need to establish an origin somehow. A useful way to do this is to set an origin at one corner of the part, based on its physical edges. How do you tell the DRO (or hand wheels) where the edges are? Enter the edge finder.
If you have an opinion about C++, chances are you either love it for its extensiveness and versatility, or you hate it for its bloated complexity and would rather stick to alternative languages on both sides of the spectrum. Either way, here’s your chance to form a new opinion about the language. The C++ standard committee has recently gathered to work on finalizing the language standard’s newest revision, C++20, deciding on all the new features that will come to C++’s next major release.
After C++17, this will be the sixth revision of the C++ standard, and the language has come a long way from its “being a superset of C” times. Frankly, when it comes to loving or hating the language, I haven’t fully made up my own mind about it yet. My biggest issue with it is that “programming in C++” can just mean so many different things nowadays, from a trivial “C with classes” style to writing code that will make Perl look like prose. C++ has become such a feature-rich and downright overwhelming language over all these years, and with all the additions coming with C++20, things won’t get easier. Although, they also won’t get harder. Well, at least not necessarily. I guess? Well, it’s complex, but that’s simply the nature of the language.
Anyway, the list of new features is long, combining all the specification proposals is even longer, and each and every one of these additions could fill its own, full-blown article. But to get a rough idea about what’s going to come to C++ next year, let’s have a condensed look at some of these major new features, changes, and additions that will await us in C++20. From better type checking and compiler errors messages to Python-like string handling and plans to replace the #include system, there’s a lot at play here!
The basic technology of radio hasn’t changed much since an Italian marquis first blasted telegraph messages across the Atlantic using a souped-up spark plug and a couple of coils of wire. Then as now, receiving radio waves relies on antennas of just the right shape and size to use the energy in the radio waves to induce a current that can be amplified, filtered, and demodulated, and changed into an audio waveform.
That basic equation may be set to change soon, though, as direct receivers made from an exotic phase of matter are developed and commercialized. Atomic radio, which does not rely on the trappings of traditional radio receivers, is poised to open a new window on the RF spectrum, one that is less subject to interference, takes up less space, and has much broader bandwidth than current receiver technologies. And surprisingly, it relies on just a small cloud of gas and a couple of lasers to work.
It would be fair to say that the Raspberry Pi team hasn’t been without its share of hardware issues, with the Raspberry Pi 2 being camera shy, the Raspberry Pi PoE HAT suffering from a rather embarrassing USB power issue, and now the all-new Raspberry Pi 4 is the first to have USB-C power delivery, but it doesn’t do USB-C very well unless you go for a ‘dumb’ cable.
Join me below for a brief recap of those previous issues, and an in-depth summary of USB-C, the differences between regular and electronically marked (e-marked) cables, and why detection logic might be making your brand-new Raspberry Pi 4 look like an analogue set of headphones to the power delivery hardware.
Harvesting delicate fruit and vegetables with robots is hard, and increasingly us humans no longer want to do these jobs. The pressure to find engineering solutions is intense and more and more machines of different shapes and sizes have recently been emerging in an attempt to alleviate the problem. Additionally, each crop is often quite different from one another and so, for example, a strawberry picking machine can not be used for harvesting lettuce.
The machine uses YOLO3 detection and classification networks to get localisation coordinates of the crop and then check if it’s ready for harvest, or diseased. A standard UR10 robotic arm then positions the harvesting mechanism over the lettuce, getting force feedback through the arm joints to detect when it hits the ground. A pneumatically actuated cutting blade then attempts to cut the lettuce at exactly the right height below the lettuce head in order to satisfy the very exacting requirements of the supermarkets.
Rather strangely, the main control hardware is just a standard laptop which handles 2 consumer grade USB cameras with overall combined detection and classification speeds of about 0.212 seconds. The software is ROS (Robot Operating System) with custom nodes written in Python by members of the team.
Although the machine is slow and under-powered, we were very impressed with the fact that it seemed to work quite well. This particular project has been ongoing for several years now and the machine rebuilt 16 times! These types of machines are currently (2019) very much in their infancy and we can expect to see many more attempts at cracking these difficult engineering tasks in the next few years.
While recent commercial competition has dropped the cost of reaching orbit to a point that many would have deemed impossible just a decade ago, it’s still incredibly expensive. We’ve moved on from the days where space was solely the domain of world superpowers into an era where multi-billion dollar companies can join on on the fun, but the technological leaps required to reduce it much further are still largely relegated to the drawing board. For the time being, thing’s are as good as they’re going to get.
If we can’t count on the per pound cost of an orbital launch to keep dropping over the next few years, the next best option would logically be to design spacecraft that are smaller and lighter. Thankfully, that part is fairly easy. The smartphone revolution means we can already pack an incredible amount sensors and processing power into something that can fit in the palm of your hand. But there’s a catch: the Tsiolkovsky rocket equation.
Often referred to as simply the “rocket equation”, it allows you to calculate (among other things) the ratio of a vehicle’s useful cargo to its total mass. For an orbital rocket, this figure is very small. Even with a modern launcher like the Falcon 9, the payload makes up less than 5% of the liftoff weight. In other words, the laws of physics demand that orbital rockets are huge.
Unfortunately, the cost of operating such a rocket doesn’t scale with how much mass it’s carrying. No matter how light the payload is, SpaceX is going to want around $60,000,000 USD to launch the Falcon 9. But what if you packed it full of dozens, or even hundreds, of smaller satellites? If they all belong to the same operator, then it’s an extremely cost-effective way to fly. On the other hand, if all those “passengers” belong to different groups that split the cost of the launch, each individual operator could be looking at a hundredfold price reduction.
By pretty much any metric you care to use, the last couple of decades has been very good for the open source movement. There was plenty of pushback in the early days, back when the only people passionate about the idea were the Graybeards in the IT department. But as time went on, more and more developers and eventually companies saw the benefit of sharing what they were working on. Today, open source is effectively the law of the land in many fields, and you don’t have to look far to find the community openly denouncing groups who are keeping their source under lock and key.
In the last few years, we’ve even seen the idea gain traction in the hardware field. While it’s not nearly as prevalent as opening up the software side of things, today it’s not uncommon to see hardware schematics and PCB design files included in project documentation. So not only can you download an open source operating system, web browser, and office suite, but you can also pull down all the information you need to build everything from a handheld game system to an autonomous submarine.
With so many projects pulling back the curtain, it’s not unreasonable to wonder where the limits are. There’s understandably some concerns about the emerging field of biohacking, and anyone with a decent 3D printer can download the files necessary to produce a rudimentary firearm. Now that the open source genie is out of the bottle, it seems there’s precious little that you can’t download from your favorite repository.
Scratching an exceptionally surprising entry off that list is Transatomic, who late last year uploaded the design for their TAP-520 nuclear reactor to GitHub. That’s right, now anyone with git, some uranium, and a few billion dollars of seed money can have their very own Molten Salt Reactor (MSR). Well, that was the idea at least.
So six months after Transatomic dumped a little under 100 MB worth of reactor documentation on GitHub, is the world any closer to forkable nuclear power? Let’s find out.