Neural Network Pies That Might Be Worth A Try

Neural networks are a key technology in the field of machine learning. A common technique is training them with sample data, and then asking them to create something new in the same vein. AI researcher [Janelle Shane] decided to task a neural network with a fun task – inventing new kinds of pie.

Using the char-rnn library, the network was initially trained on a sample of 2237 pie recipe titles, sourced from around the internet. Early iterations struggled to even spell “pie”, but as the network improved, so did the results. Where we can’t imagine how one would even make a “Sweesh Pie Ipple Pie”, later results, such as the “Impossible Maple Spinach Apple Pie” seem far more cromulent by comparison.

At this point, [Janelle] decided to mix things up, stirring in a further sample consisting of the names of various cookies and apples. The data were carefully sorted such that the network still prioritized pies, but this additional data gave the model a richer library to draw from. This led to such home-baked classics as Flangerson’s Blusty Tart and Chicken Pineapple Cream Pie.

On the surface, it’s a fun project with whimsical output, but fundamentally it highlights how much can be accomplished these days by standing on the shoulders of giants, so to speak. We’ve seen [Janelle]’s output before, too – naming tomatoes, no less.

DIY Telepresence Robot Built From Off-The-Shelf Parts

Petite, but it does the job. Note the huge LED headlight in the center.

Telepresence hasn’t taken off in a big way just yet; it may take some time for society to adjust to robotic simulacra standing in for humans in face-to-face communications. Regardless, it’s an area of continuous development, and [MakerMan] has weighed in with a tidy DIY build that does the job.

It’s a build that relies on an assemblage of off-the-shelf parts to quickly put together a telepresence robot. Real-time video and audio communications are easily handled by a Huawei smartphone running Skype, set up to automatically answer video calls at all times. The phone is placed onto the robotic chassis using a car cell phone holder, attached to the body with a suction cup. The drive is a typical two-motor skid steer system with rear caster, controlled by a microcontroller connected to the phone.

Operation is simple. The user runs a custom app on a remote phone, which handles video calling of the robot’s phone, and provides touchscreen controls for movement. While the robot is a swift mover, it’s really only sized for tabletop operation — unless you wish to talk to your contact’s feet. However, we can imagine there has to be some charm in driving a pint-sized ‘bot up and down the conference table when Sales and Marketing need to be whipped back into shape.

It’s a build that shows that not everything has to be a 12-month process of research and development and integration. Sometimes, you can hit all the right notes by cleverly lacing together a few of the right eBay modules. Getting remote video right can be hard, too – as we’ve seen before.

Foam Airboat Is Cheap RC Fun

Archer fans and residents of Louisiana will already be familiar with the concept of the airboat. Put a powerful engine running an aircraft prop on a flat-bottomed hull, and you’ve got an excellent way to traverse the marshes of the American South. While a fully-fledged airboat might run you the best part of $100,000, this no-frills radio-controlled version is great fun at a much lower price.

The hull is built on a sheet of foam, which is cheap, readily available, and suitably buoyant for the task. It’s then kitted out with a brushless motor to run the prop and a servo to control the rudder. Lace it up with a radio receiver and speed controller and you’re good to go.

The build could readily be completed in well under a couple of hours, and is a great one to tackle with kids due to its mechanical simplicity. There’s room for extra creativity too – you can always substitute a watermelon if you’re feeling peckish. Video after the break. Continue reading “Foam Airboat Is Cheap RC Fun” →

Re-enacting TRON On The Apple IIgs

TRON is a science fiction classic, hitting cinemas in the midst of the burgeoning home computer era. It’s the film that created the famous light cycle, which spawned many video game recreations in the following years. Many years ago now, [Daniel] decided to flex his programming muscles by coding a version of the game for the Apple IIgs, with accidentally excellent results.

In the film, the characters find an escape from the light cycle game by forcing another player to crash into the walls of the play area. The resulting explosion left a hole, allowing the players to exit the light cycle game and explore the rest of the computer. Amusingly, due to a coding oversight, [Daniel] had created exactly this same flaw in his own code.

[Daniel]’s game differed from the original in that players were provided with missiles to destroy enemy trails. However, these missiles did not discriminate, and due to the simplicity of the code, were able to destroy the boundary on the play area. This was discovered when the computer player tried to escape an otherwise impossible situation. Upon blowing a hole in the arena wall, the computer player proceeded to drive off the screen – into invalid memory. This led to the computer crashing in short order, due to the unprotected memory space of the Apple II platform.

It’s a case of code imitating art – and completely by accident. The game managed to replicate the light cycle escape from the film entirely due to the unexpected behaviour of the simple missile code. [Daniel] steps through the code and how the bug happened, and covers the underlying principle behind the resulting crashes. It’s an entertaining tale of the risks of coding at low level; something we don’t always run into with today’s modern interpreted languages.

Thirsty for more tales of hacking the Apple II? How about going back in time to fix a 37 year old bug?

Centurion Bridge Layer, Now In RC

Radio controlled models are great fun. Most of us have had a few RC cars as children and maybe dabbled with the occasional helicopter or drone. It’s a rare breed of modeler, however, that gets to drive a radio-controlled bridge laying tank.

The lads prepare to fight the good fight.

The model is a replica of the British Centurion Bridgelayer – a modified tank designed to allow mechanized units to readily cross rivers and similar obstacles in European battlefields. While the genuine article relied on hydraulics, the RC version takes a different tack. [hawkeye3guns] built custom linear actuators out of motors, gears, and brass to deploy the bridge.

The build shows other smart techniques of the enterprising modeler. Rather than start from scratch, the Centurion is built on a modified KV tank hull. After the modifications were complete, the tank received a lick of paint in the requisite British Army green. The final result is rather impressive.

It goes to show what can be achieved with some off-the-shelf parts and ingenuity. We’ve seen other impressive RC tanks before – like this French build with a homebrew targeting computer.

How To Evolve A Radio

Evolutionary algorithms are an interesting topic of study. Rather then relying on human ingenuity and investigation to create new designs, instead, an algorithm is given a target to achieve, and creates “offspring”, iterating in an evolutionary manner to create offspring that get closer to the target with each generation.

This method can be applied to the design of electronic circuits, and is sometimes referred to as “hardware evolution”. A team from Duke University attempted exactly this, aiming to produce an oscillator using evolutionary techniques.

The team used a platform called the “evolvable motherboard”, or EM. The EM is a platform controlled by an attached computer, consisting of reconfigurable solid state switches that allow attached circuit components to be interconnected in every combination possible. These components may be virtually any electronic component; in this experiment, 10 bipolar transistors were used.

The evolutionary algorithm was given a fitness function that rewarded output amplitude and frequency, aiming to create an oscillator operating at 25KHz. However, the team noticed some interesting emergent behavior. The algorithm tended to reward amplification behavior from the circuit, leading to many configurations that oscillated poorly, but amplified ambient noise. In the end, the algorithm developed circuit configurations that acted as a radio, picking up and amplifying signals from the surrounding environment, rather than oscillating on their own. The evolutionary algorithm took advantage of the interaction between not only the circuit elements, but effects such as the parasitic capacitance introduced by the switching matrix and appeared to use the PCB circuit traces as an antenna.

The team conclude that evolutionary algorithms used in circuit design ignore human preconceptions about how circuits work, and will take advantage of sometimes unpredictable and unexpected effects to achieve their targets. This is a blessing and a curse, bringing unconventional designs to the fore, but also creating circuits that may not work well in a generalized environment. If your “oscillator” relies on a nearby noise source to operate, it may operate unpredictably in the field, for example.

We’ve seen evolutionary algorithms used before, such as being applied to robotic design.

The Naughty AIs That Gamed The System

Artificial intelligence (AI) is undergoing somewhat of a renaissance in the last few years. There’s been plenty of research into neural networks and other technologies, often based around teaching an AI system to achieve certain goals or targets. However, this method of training is fraught with danger, because just like in the movies – the computer doesn’t always play fair.

It’s often very much a case of the AI doing exactly what it’s told, rather than exactly what you intended. Like a devious child who will gladly go to bed in the literal sense, but will not actually sleep, this can cause unexpected, and often quite hilarious results. [Victoria] has created a master list of scholarly references regarding exactly this.

The list spans a wide range of cases. There’s the amusing evolutionary algorithm designed to create creatures capable of high-speed movement, which merely spawned very tall creatures that generated these speeds by falling over. More worryingly, there’s the AI trained to identify toxic and edible mushrooms, which simply picked up on the fact that it was presented with the two types in alternating order. This ended up being an unreliable model in the real world. Similarly, the model designed to assess malignancy of skin cancers determined that lesions photographed with rulers for scale were more likely to be cancerous.

[Victoria] refers to this as “specification gaming”. One can draw parallels to classic sci-fi stories around the “Laws of Robotics”, where robots take such laws to their literal extremes, often causing great harm in the process. It’s an interesting discussion of the difficulty in training artificially intelligent systems to achieve their set goals without undesirable side effects.

We’ve seen plenty of work in this area before – like this use of evolutionary algorithms in circuit design.