Raspberry Pi’s are a little weird. They mostly get crammed into the slots microcontrollers used to live in. The nice part about microcontrollers is that they just turn on and start going. There’s no OS to boot. No file system to mount. Of course the downside to microcontrollers is often that there’s no OS to boot and file system to mount. Regardless, mostly you’ve got to spend a bit configuring a Raspbian install before a Raspberry Pi really starts to encroach on the microcontroller’s territory.
Pi Bakery abstracts all this. You can drag blocks, representing scripts, in the order you’d like them run. If you want to your Pi to boot up, connect to WiFi, and then start a VNC server it’s as easy a dragging the blocks in the right order and filling in the blanks. You can see an example of it in operation in the video after the break.
With so many systems depending on Linux, the secure shell SSH has become a staple for many developers. If you are connected to your Raspberry Pi via a cable or a wireless router a few feet away, SSH can provide you with an encrypted connection straight to the box. However, if you have a system out in a swamp somewhere with intermittent slow network access, SSH can be a real pain. When your IP address can change (for example, roaming on a cellular network), SSH has problems, too.
To combat these and other problems, you might consider an open source program called Mosh (mobile shell). There’s two parts to Mosh. One part works as a server while the other is the client application. Neither of these require root access. You can see a video about Mosh below.
Using Mosh is pretty similar to using SSH (and, in fact, you can use SSH to initially launch Mosh). The Mosh server has a system that synchronizes the screen, so it doesn’t waste time sending characters that won’t really appear to the user. In addition, the client keeps its own notion of the screen and it attempts to handle some operations locally. For example, in SSH every character you type echos through the server. While this is useful to know the server is there, it isn’t good for responsiveness. Mosh handles echo locally and also predicts certain things like insertion and deletion of characters. Unlike SSH, Mosh uses UDP datagrams so packet loss isn’t a big deal.
In fact, if you switch networks or if your computer sleeps and wakes up, Mosh will stay “connected.” Because Mosh doesn’t send data you won’t see, you can easily interrupt a long scrolling output (Mosh selects a frame rate for scrolling based on the network connection’s quality).
Seeing the Future
When you type something in Mosh, it might make a prediction. If the network isn’t robust, Mosh will presume that most characters will appear at the current cursor location. It also expects certain behavior of keys like backspace, right arrow, and left arrow. Of course, there’s a chance it is wrong, so it underlines guesses until they are proven right. The software gathers batches of predicted input (epochs) that it validates (or refutes) as a group. Certain characters (like the up and down arrow) heuristically start new epochs.
For example, if you start typing inside emacs (or vi), you will start building an epoch that does not display on the screen. When data comes back from the host computer that validates the guess as correct, Mosh will display the epoch and continue to display its guesses until something (like an up or down arrow) changes the epoch. Then it will go back to not performing the local echo until it is once again correctly predicting. All this works well, but you can turn predictions off if you wish.
If you want to see the behavior firsthand, open up a Mosh session and start typing on a shell prompt. For example, consider you are going to enter this command:
find / -name 'mosh*' -print
Type up to the first slash. Now disconnect your network (pull the cable or shut off your wireless). Type some more of the command and you’ll see the speculative characters show up underlined (see below; the red cursor indicates the connection is currently not up). Now either reconnect the network or turn on your phone’s hot spot or otherwise connect to a different network. Finish typing the command and it should all work.
The Kitchen Sync
Mosh also claims to solve a host of other display-related problems stemming from the use of Unicode and escape characters. However, the real engine is the synchronization piece which can actually keep any abstract object in sync across two devices. Mosh uses two instances of this sync protocol (SSP); one to keep the screen buffer and one to handle the input buffer. The reality is that Mosh is just a terminal emulator built over SSP. It seems like SSP could find use in other applications where two machines need to stay in sync over a low-quality network.
Mosh is available on a surprising number of platforms. In addition to the usual suspects, you can get Mosh as part of the JuiceSSH client on Android. Windows users can use Cygwin or a version that runs within Chrome. It also runs on a Mac or any of several Linux and BSD distributions. Of course, you can also build it from source. Installing it on Raspian is as easy as issuing the usual command:
sudo apt-get install mosh
If you are just a desktop or server Linux user, you might never care about Mosh. But if you deploy systems to places where network connectivity is spotty or changes, it is worth a look. Even more importantly, if you have a need to keep an arbitrary object in sync between two different computers despite a poor network, you should really check out SSP to see if you can bend it to your will.
If you have been off trick-or-treating and returned home with an embarassment of candy, what on earth can you do to mange the problem and sort it by brand?
Yes, it’s an issue that so many of us have had to face at this time of year. So much a challenge, that the folks at [Dexter Industries] have made a robotic candy-sorter to automate the task.
OK, there’s something of the tongue-in-cheek about the application. But the technology they’ve used is interesting, and worth a second look. Hardware wise it’s a Lego Mindstorms conveyor and hopper controlled by a Raspberry Pi through the BrickPi interface. All very well, but it’s in the software that the interest lies. They use the Raspberry Pi’s camera to take a picture to send off to Google Cloud Vision, which they then query to return a guess at the brand of the candy in question. The value returned is then compared to a list of brands to keep or donate to another family member, and the hopper tips the bar into the respective pile. They provide full build details and code, as well as the video we’ve put below the break. So simple a child can explain it, sort of.
Machine vision remains a challenge, as we can see from our list of stories tagged with it; only a few of them over all the years Hackaday has been in existence. Using a cloud service might not be to everyone’s taste, but it provides an alternative route into machine vision as well as the extra power of the Google engine, and could open up the technology to makers who might not otherwise use it.
Posts
