Unsatisfied with the present options for chess computers and preferring the feel of a real board and pieces, [Max Dobres] decided that his best option would be to build his own.

Light and dark wood veneer on 8mm MDF board created a board that was thin enough for adding LEDs to display moves and for the 10mm x 1mm neodymium magnets in the pieces to trip the reed switches under each space. The LEDs were wired in a matrix and connected to an Arduino Uno by a MAX7219 LED driver, while the reed switches were connected via a Centipede card. [Dobres] notes that you’ll want to test that the reed switches are positioned correctly — otherwise they might not detect the pieces!

A small LCD screen and four buttons also connect to the Arduino for configuring options a number of options, computer difficulty, and play styles, while a Raspberry Pi acts as the main computer.

The Raspberry Pi is using ChessBoard 2.05 as a rule set with consideration for special moves (such as en passant and castling). It’s currently unsupported but used with permission by its creator, John Eriksson. The chess program Stockfish is the actual engine; be sure to adjust the skill of the AI, as it defaults to an ELO of 2600! Unfortunately, it’s a rather finicky program, only running on Python 2.7. If that doesn’t appeal to you, [Dobres] has provided a nice list of other options to help you with your own build.

He has recently updated his design and done away with the need for the Arduino in the process which — especially if you use the Pi Zero — drops the cost of this project significantly. That should leave you with enough room in your budget to build a robot to make the moves for you!

[via Max Dobres]

Daughter boards for microcontroller systems, whether they are shields, hats, feathers, capes, or whatever, are a convenient way to add sensors and controllers. Well, most of the time they are until challenges arise trying to stack multiple boards. Then you find the board you want to be mid-stack doesn’t have stackable headers, the top LCD board blocks the RF from a lower board, and extra headers are needed to provide clearance for the cabling to the servos, motors, and inputs. Then you find some boards try to use the pins for different purposes. Software gets into the act when support libraries want to use the same timer or other resources for different purposes. It can become a mess.

The alternative is to unstack the stack and use external boards. I took this approach in 2013 for a robotics competition. The computer on the robots was an ITX system which precluded using daughter boards, and USB ports were my interface of choice. I used a servo controller and two motor controllers from Pololu. They are still available and I’m using them on a rebuild, this time using the Raspberry Pi as the brain. USB isn’t the only option, though. A quick search found boards at Adafruit, Robotshop, and Sparkfun that use I²C.

This approach has challenges and benefits. A stack of daughter boards makes a neat package, where external boards makes a tangle of wires. Random sizes can make mounting a challenge. Providing power can also be a hassle because of the random placement of power pins. You can’t rely on USB power, especially from a Raspberry Pi whose USB is power limited.

On the other hand, external boards can offload processing from your main processor. Once a command is sent, these boards handle all the details including refresh requirements. They are likely to provide capabilities beyond the microcontroller software libraries since their processors are dedicated to the task.

I am using an 18-channel board from the Pololu Maestro Servo Controller family of boards that control from 6 to 24 servos using a single board. You might find the Adafruit 16 channel I²C board a useful alternative. For motor control I turned to the Pololu Simple Motor Controller family using one that will handle 18 amps. Others will handle from 7 to 25 amps. Or consider the Sparkfun Serial Controlled Motor Driver. Another source for USB controllers is Phidgets. I experimented with one of their spatial devices for the original robot. I should have used it to measure the tilt since one of my robots rolled over on a hill. Ooops!

Servo Control

The board currently installed on my robot is the Mini Maestro 18. The Maestro provides control over the servo speed, acceleration and movement limits. A home position can be set for startup or when errors occur. You can even do scripting or set movement sequences to play on command.

On the hardware side, the Maestro also allows channels to be used for digital input or output, and some channels for analog input. On some there is one channel for pulse width modulation output. An onboard regulator converts the servo power input to the voltage needed by the processor, simplifying part of the power distribution challenge.

My previous robot used the Maestro to control pan and tilt servos for camera positioning, a servo to lift samples from the ground, and a safety LED. Two analog inputs from current sensors on the motors helped avoid burnout during stalls, and four inputs from a simple RF key fob transmitter provided control. The latter came in handy for testing. I’d program a test sequence such as starting a 360° camera scan for landmarks or drive onto the starting platform and drop the sample. A button press on the key fob would initiate the activity. One button was always set up as an emergency halt to stop a rampaging robot. The rebuild is following this pattern with some additions.

Motor Controller

The two Simple Motor Controllers (SMC) each handled the three motors on either side of the Wild Thumper chassis. The SMC does more than just control the motor speed and direction. You can set acceleration, braking, and whether forward and reverse operate at the same or different speeds. The board monitors a number of error conditions for safety. These stop the motor and prohibit movement until cleared. Such blocking errors include lost communications, low input voltage, or drivers overheating.

An additional capability I found extremely helpful is the ability to read signals from a radio control (RC) receiver. These signals can be used to control the motor and, with some cross wiring between two controllers, provide differential drive control. This is useful for driving the robot to a new location using an RC transmitter. I didn’t use the RC inputs directly. Instead I read the RC inputs and issued the control commands from my program. This let me monitor the speed in my program logs for correlation with the other logged data. I also used an input to command the robot into autonomous or RC control operations. There are also two analog inputs that can be used to directly control the motor and can be read through commands.

Serial Communications

USB ports were my choice for communications but there is also a TTL level serial port with the standard RX and TX pins. This port can be used by the Raspberry Pi, Arduino, or any other microcontroller that has a TTL serial port.

The Maestro boards using USB appear as two serial ports. One is the command port that communications with the Maestro processor. The other is a TTL port. This port can serve as simply a USB to TTL serial port converter to allow communications with other boards, even from another vendor. Another use of the TTL port is to daisy chain Pololu boards. I could attach the SMC boards in this manner and save two USB ports for other devices. These boards support this by having a TXIN pin that ANDs the TX signal from the connected board with the TX on the board.

Both of these controllers support a few different communications protocols. I use the one Pololu created and is available on some of their other products. The command details are different between the boards, but the basic command structure is the same. They call it their binary protocol, and the basic format follows:

0xAA, <device address>, <command>, <optional data>, <crc>

All the fields are single bytes except for the data field which is frequently 2 bytes to transmit 16-bit data. The returned data is only one or two bytes with no additional formatting. Note they provide for detecting errors in the message by using a CRC (cyclical redundancy check). This is probably not critical over USB but a TTL line might receive noise from motors, servos, and other devices. A CRC error sets a bit in the error register that can be read if the command is critical.

I wrote my own code, C++ of course, for the PC and converted it just now to the Raspberry Pi. The main change is the different serial port code needed by Linux and Windows. Pololu now provides Arduino source for the protocol making it easy to use these boards with that family of controller boards.

Wrap Up

The chassis, Pi, and these boards are now installed on the Wild Thumper chassis along with a pan and tilt controlled by servos. A safety LED is on when power is applied and flashes when the robot is actively controlling the system. A LiPo battery powers all but the Pi because I need to configure a battery eliminator circuit to provide five volts. I’m powering it temporarily using a USB battery pack.

A test program, cross compiled from my desktop, moves the robot forward, pivots left than right, and then reverses. The pan / tilt moves and the LED flashes. I originally used a web camera for vision processing but will switch to the Pi camera since it is better. The Neato lidar discussed in a previous article will soon find a place onboard, along with an accelerometer to detect possible rollovers.

I’m sure I could have done this using Pi daughter boards despite the challenges I mentioned earlier. There are trade-offs to both approaches that need to be considered when working on a project. But there is one final advantage to the external boards: they have a lot of twinkly LEDs.

Product photos from Pololu.

Seems like just about every hackerspace eventually ends up with an old vending machine that gets hacked and modded to serve up parts, tools, and consumables. But why don’t more hackerspaces build their own vending machines from scratch? Because as [Ryan Bates] found out, building a DIY vending machine isn’t as easy as it looks.

[Ryan]’s “Venduino” has a lot of hackerspace standard components – laser-cut birch plywood case, Parallax continuous rotation servos, an LCD screen from an old Nokia phone, and of course an Arduino. The design is simple, but the devil is in the details. The machine makes no attempt to validate the coins going into it, the product augurs are not quite optimized to dispense reliably, and the whole machine can be cleaned out of product with a few quick shakes. Granted, [Ryan] isn’t trying to build a reliable money-making machine, but his travails only underscore the quality engineering behind modern vending machines. It might not seem like it when your Cheetos are dangling from the end of an auger, but think about how many successful transactions the real things process in an environment with a lot of variables.

Of course, every failure mode is just something to improve in the next version, but as it is this is still a neat project with some great ideas. If you’re more interested in the workings of commercial machines, check out our posts on listening in on vending machine comms or a Tweeting vending machine.

[via r/arduino]

The Raspberry Pi and other similar Linux-based single board computers simplify many projects. However, one issue with Linux is that it doesn’t like being turned off abruptly. Things have gotten better, and you can certainly configure things to minimize the risk, but–in general–shutting a Linux system down while it is running will eventually lead to file system corruption.

If your project has an interface, you can always provide a shutdown option, but that doesn’t help if your application is headless. You can provide a shutdown button, but that leaves the problem of turning the device back on.

[Ivan] solved this problem with–what else–an Arduino (see the video below). Simplistically, the Arduino reads a button and uses a FET to turn off the power to the Pi. The reason for the Arduino, is that the tiny processor (which draws less than a Pi and doesn’t mind being shut down abruptly) can log into the Pi and properly shut it down. The real advantage, though, is that you could use other Arduino inputs to determine when to turn the Pi on and off.

For example, it is easy to imagine a Pi in an automotive application where the Arduino would sense the ignition was off for a certain period of time and then go ahead and shut off the Pi. Or maybe the Pi needs to be turned on when a motion sensor fires and then turned off again once there is no motion for a particular time period. Any of these strategies would be simple to build with the Arduino.

We’ve seen a similar project that used an IR remote as the trigger instead of a physical button. If you are afraid the Pi will just lose power unexpectedly, you might consider a battery backup. If powering a Pi with regular electricity is too tame for you, try steam.

[John Fin] put a lot of work into his Ghostbuster’s proton pack prop with full-featured user control and effects. What appealed to us well beyond the exquisite build is the extra effort taken to write down the whole process in a PDF for anyone wishing to imitate him.

We all know that a lot of famous props are creatively rearranged household items. The famous Mr. Fusion from Back to The Future is actually a Krups coffee grinder with some logos adhered.

[John]’s prop is no different. The cyclotron is a five gallon bucket. A garlic powder container fills another function. As you look at it more and more items can be picked out. Is that a spark plug wire? The handles on that are suspiciously similar to a power tool case’s. It all comes together, and while it’s not screen accurate you’d have to be an extreme prop fanatic to tell.

Naturally, the core of [John]’s prop is an Arduino. It stores the sound files on a SD Card shield. It controls all the lights sounds and motors on the prop. This isn’t quite a point and shoot. You must toggle on the power, generator, and arming mechanisms before actually firing. If you do it out of order, the electronics will issue an alarm as warning, and each step in the process has its own unique audio and animated lighting.

Since the Proton Pack went so well, he also built a PKE meter and Ghost Trap to go along with his backpack. He’s ready to take on Vigo at anytime. You can see a video of his prop in action after the break.

Numbers are wonderful things when applied to technical specifications. Take [Bobricius]’ handheld Arduino-based game console. With an 8×8 LED matrix for a display it’s not going to win any prizes, but while he’s pushing the boundaries of dubious specification claims he’s not strictly telling any lies with his tongue-in-cheek statement that the graphics are 64-bit.

Jokes aside, it’s a neatly done build using a DIP version of the Arduino MCU and all through-hole components on a custom PCB. Power comes from a CR2032 cell, and it includes three buttons and a small piezoelectric speaker. He’s implemented a whole slew of games, including clones of Pong, Breakout, and Tetris, and judging by the video below it’s surprisingly playable.

Now you might look at this console and wonder what the big deal is. After all, there are plenty of similar designs to be found, and it’s nothing new. Of course, it’s a neat project for any hacker or maker, but we can see that this would make a great starter project for the younger person in your life who wants to try their hands at building something electronic. All through-hole construction for easy soldering, and a neat game at the end of it all.

He’s posted a full write-up of the design process as well as the hackaday.io page linked above, so if you fancy building one yourself there’s nothing to stop you too squeezing 64 bits of graphical goodness from an Arduino.

This isn’t the first Arduino game we’ve shown you here at Hackaday, we’ve unmasked the secrets of the Arduinocade, featured another handheld Arduino game with an LCD screen, and a beautifully coded console using a TFT among many more.

Last fall, I grabbed a robot arm from Robot Geeks when they were on sale at Thanksgiving. The arm uses servos to rotate the base and move the joints and gripper. These work well enough but I found one aspect of the arm frustrating. When you apply power, the software commands the servos to move to home position. The movement is sufficiently violent it can cause the entire arm to jump.

This jump occurs because there is no position feedback to the Arduino controller leaving it unable to know the positions of the arm’s servos and move them slowly to home. I pondered how to add this feedback using sensors, imposing the limitation that they couldn’t be large or require replacing existing parts. I decided to try adding accelerometers on each arm section.

Accelerometers, being affected by gravity when on a planet, provide an absolute reference because they always report the direction of down. With an accelerometer I can calculate the angle of an arm section with respect to the direction of gravitational acceleration.

Before discussing the accelerometers, take a look at the picture of the arm. An accelerometer would be added to each section of the arm between the controlling servos.

Accelerometers

Gravity tugs everything toward the center of the mass of the Earth. It is a force that creates an acceleration exactly just like what you feel when a vehicle begins to move or stop. The force of gravity creates an acceleration of 1 g which is 9.8 m/s² or 32.15 ft/s². An accelerometer measures this force.

Integrated circuit accelerometers are inexpensive and small devices readily usable by hackers. One reason they are inexpensive is the high demand for them in smart phones. These small devices are based on etching mechanical structures within the integrated circuit using a technology called MEMS (Microelectromechanical systems).

One design for a MEMS accelerometer is basically a variable capacitor. One plate is fixed and the other mounted some distance away on a spring suspension. When the device is accelerated the suspended plate moves closer or further away from the fixed plate, changing the capacitance. Another uses piezo-resistive material to measure the stress on an arm caused by acceleration.

A single axis accelerometer measures acceleration in only one direction. If positioned so the direction is up and down it will measure the force of gravity but will not detect horizontal acceleration. When the device is tilted between horizontal and vertical the force of gravity is only partially affecting the measurement. This provides the ability to measure the angle of the device with the direction of gravity. The acceleration felt along the tilted axis, for a tilt angle can be calculated by:

Knowing the output of the accelerometer we can determine the angle by taking the inverse sine, the arc sine, of the output:

If you rotate a single axis device through 360° the output is a sine wave. Start with the device outputting zero and consider that 0°. As it rotates, the output is 1 when the angle is 90° and back to zero at 180°. Continuing the rotation, the output becomes -1 at 270°, or -90°, degrees and back to zero at 360°, or 0°.

Notice on the chart that between -60° and 60° the output is nearly linear. This is the best orientation for measuring inclination. Increases in inclination are not as accurate on the other portions of the curve. Also notice that the same output is generated for 45° and 135° (90° + 45°) creating an ambiguity. With a single axis you cannot determine which of those angles is measured.

Putting two accelerometers at a right angle to one another creates a 2-axis device which solves the ambiguity problem. As the device is rotated through 360° the outputs are 90° out of phase, the same relationship as the sine and cosine. By combining the measurements there is a unique solution for every angle throughout 360°. The acceleration due to gravity at each angle is given by:

which leads to calculating the angle by:

Actually, one more step is needed to determine the sign of the angle. This requires examining the sign of the values for the X and Y axis. It isn’t necessary to go into this here because a standard programming function handles this automatically.

The orientation of a quadcopter requires a 3-axis accelerometer. The calculations for the three spherical angles combine all three inputs for their results. You’ll need to study this carefully because the standard trigonometric equations can cause anomalies when the quadcopter flips.

First Pass Solution

Accelerometers are easily obtained and relatively cheap. You can find them mounted on breakout boards with voltage regulators and all the supporting circuits from the usual vendors. They are available for 1 to 3 axis, various amounts of g force, and providing either analog or digital outputs. Analog devices need an analog input for each axis being measured. Digital outputs use I²C or SPI buses for communications. I decided to use analog devices because digital units typically only allow two addresses and the arm needs three devices, one for each section.

The robot arm uses an Arduino board so there are at least 6 analog inputs. The original board was a Robot Geek Geekduino, their version of the Arduino Duemilanove, with 8 analog inputs. Unfortunately, when working with the arm I broke the USB connector so switched to a Uno equivalent having only 6 inputs.

My choice for accelerometer is a 3-axis, ±3 g accelerometer breakout from Adafruit, their ADXL335. It has one analog output for each axis. Since I’m measuring three joints that means three boards which adds up to 9 analog outputs.

Because of the geometry of the arm, however, I only need 5 inputs for these three joints. The shoulder joint only moves from 0° to 180°. This can be handled by a single axis accelerometer by mounting it to read acceleration of 1 g for 0° and -1g for 180°. That provides a unique output for the necessary angles. The elbow and wrist joints each require two inputs. The third input is not needed because their motion is constrained to moving within the vertical plane of the arm.

Frame of Reference

The next issue is the frame of reference. This is a standard problem in robotics work. Early in a project, a global frame of reference is decided upon. This sets the origin for the coordinate system that the robot will follow and the direction of the three axes, usually specified as X, Y, and Z. For the arm, X is straight forward, Y is to the left, and Z is straight up. The zero point is the base of the shoulder. This also defines a global frame for rotation of the arms limbs with zero degrees also toward the front.

Sensors and controllers each have their own frame of reference. Any differences among these devices and the global frame need to be resolved in software. The shoulder servo’s frame of reference is 0° at the back of the arm and 180° at the front, a clockwise rotation. This is the reverse of the global frame. The elbow servo worked the opposite with a counter-clockwise rotation putting 180° straight up and 90° straight out when the shoulder was vertical. It is 90° off from the global frame of reference.

Sensors also have their own frame of reference. The Y-axis accelerometer measuring the shoulder orientation worked counter-clockwise. Both axis on the accelerometers measuring the elbow worked in the clock-wise direction. This may seem strange but it’s because of the different mounting orientations of the sensors.

Software

The actual code is straightforward once the frame of references are sorted out. A single axis is read from the analog input and its angle calculated with:

const int shouldery = shoulderAnalogY.read();
float shoulder_angle = degrees(asin(shouldery_value / 100.0));

The read() method scales the raw analog input values so ±1g is represented as ±100. The input to asin() is divided by 100.0 to convert to the actual g value. That suffices for the shoulder angle.

The elbow and wrist angles use values from two axis and the calculation is:

const int elbowx = elbowAnalogX.read();
const int elbowy = elbowAnalogY.read();
float elbow_angle = degrees(atan2(-elbowy, elbowx));

The atan2() function is a special version of the arc tangent calculation. It examines the signs of the input value to determine the quadrant of the angle to set the appropriate sign on its result. The negative sign on the elbowy is needed to set the appropriate quadrant. There’s the frame of reference issue, again.

Wrap Up

Adding the accelerometers solved the startup lurching problem well enough. Whether the accelerometers can be used for other purposes remains to be seen.

The accuracy of the angle measurements is not good. In part this is due to using a device that with a +/- 3 g range to measure 1/3 of the devices range, 1 g. The device outputs 0 to 3.3 volts while the Arduino is sampling for 5 volts, again losing accuracy. This might be improved by using an Arduino based on 3.3 volts. I have a couple Dues on hand so might try them. The Uno also provides for adjusting the reference voltage for analog inputs so setting it to 3.3 volts might help.

The analog values need to be calibrated with some care. Each accelerometer outputs slightly different values. Calibration requires measuring the outputs for 1 and -1 g for each axis, recording the values, and using them to scale the voltage input to acceleration. This calibration is not accurate given the other problems with the analog inputs.

Another problem is the mounting of the accelerometers on the arm’s sections. The alignment of the boards with the sections of the arm is not perfect. When the servo is positioned at 90° the accelerometer doesn’t necessarily sit at 90° with respect to the center of the earth. Of course, the servos are not that precise, either. They do not always arrive at the same position, especially when approaching from different directions. Another goal for this project was to use the accelerometer information to more precisely position the servos.

I guess I have to think about this project a bit more, including deciding what I actually want to accomplish with the arm. But then, just saying you have a robotic arm is a terrific hacking cred.

Kids love Minecraft, and a clever educator can leverage that love to teach some very practical skills. The summer class offered by the Children’s Museum in Bozeman Montana would have blown my mind if such a thing existed when we were younger. (Rather than begging one of the dads in my Boy Scout Troop to pirate Visual Studio for me, which was delivered in the form of an alarmingly tall stack of CDs.) The kids in Bozeman get to learn hardware, software, their integration, and all while playing Minecraft.

Minecraft is an immersive universe that has proven to suck in creative minds. It’s the bait that pulls the kids into the summer class but Serialcraft delivers on making the learning just as addictive. This is accomplished by providing students with physical objects that are tied to the Minecraft world in meaningful ways we just haven’t seen before (at least not all at one time). On the surface this adds physical LEDs, toggle switches, potentiometers, and joysticks to the game. But the physical controls invite understanding of the mechanisms themselves, and they’re intertwined in exciting ways, through command blocks and other in-game components that feel intuitive to the students. From their understanding of the game’s mechanics they understand the physical objects and immediately want to experiment with them in the same way they would new blocks in the game.

The thing that makes this magic possible is a Minecraft mod written by [John Allwine], who gave us a demonstration of the integration at Maker Faire Bay Area 2016. The mod allows the user to access the inputs and output of the Arduino, in this case a Pololu A-Star 32U4, from within Minecraft. For the class this is all packaged nicely in the form of a laser cut controller. It has some LEDs, two joysticks, buttons, potentiometers, and a photosensor.

As you can see in the video below the break, it’s really cool. The kids have a great time with it too. For example, [John] showed them how they can attach their unique controller to a piston in the world. Since this piston can be controlled by them alone, they quickly figured out how to make secret safe rooms for their items.

Another troublesome discovery, was that the photo transistor on the controller set the light level in the game world by altering the time of day. Kids would occasionally get up and change the world from day to night, by turning the lights in the room on or off. A feature that has a certain appeal for any Minecraft player, is rigging one of the LEDs on the controller to change brightness depending on proximity to a creeper.

There’s a lot more to the library, which is available on GitHub. The kids (and adults) have a great time learning to link the real world with the world’s most accessible fantasy world creation kit.  Great work [John]!

If necessity is the mother of invention, then inconvenience is its frustrating co-conspirator. Faced with a finicky dryer that would shut down mid-cycle with a barely audible beep if its load was uneven (leaving a soggy mass of laundry), [the0ry] decided to add the dryer to the Internet of Things so it could send them an email whenever it shut itself down.

After opening a thinger.io account, adding the soon-to-be device, and setting up the email notification process, [the0ry] combined the ESP8266 Development Board, a photosensitive resistor, and a 5V power supply on a mini breadboard. All that was left was to mount it on the dryer and direct the LDR (light-dependent resistor) to the machine’s door lock LED to trigger an email when it turned off — indicating the cycle had finished or terminated prematurely. A little tape ensured the LDR would only be tripped by the desired light source.

If you’re an apartment-dweller have WiFi in the wash area it would be awesome to see a battery-powered version you take with you. But in general this is a great hardware blueprint as many device have status LEDs that can be monitored in a similar way. If you want to keep the server in-house (literally in this case) check out the Minimal MQTT series [Elliot Williams] recently finished up. It uses a Raspberry Pi as the center server and an ESP8266 is one of the limitless examples of hardware that plays nicely with the protocol.

We love seeing hacks like this because not only does it conserve water and energy by reducing instances of rewashing, but it’s also a clever way to extend the life of an appliance and potentially save hundreds of dollars in replacing it. Add this to the bevvy of hacks that add convenience to one’s home — some of which produce delicious results.

Sometimes when browsing the websites of our global hackspace community you notice a project that’s attractive not necessarily because of what it does or its technology but because of its presentation. So it is with the subject of this article, [Kris] needed a house temperature monitor and found a 1960s slide viewer made an excellent choice for its housing.

The monitor itself is a fairly straightforward Arduino build using a couple of DS18B20 1-wire temperature sensors and a real-time-clock module and displaying their readings on a small OLED screen. Its code can be found on this mailing list thread if you are interested. The display presented a problem as it needed to be reasonably large, yet fairly dim so it could be read at night without being bright enough to interrupt sleep.

A variety of projection techniques were tried, involving lenses from a projection clock, a magnifying glass, and a Google Cardboard clone. Sadly none of these lenses had the required focal length. Eventually the slide viewer was chosen because it was pointed out that the OLED screen was about the same size as a photographic slide.

Slide viewers are part of the familiar ephemera of the analog era that most people over 60 may still have taking up drawer space somewhere but may well be completely alien to anyone under about 30. They were a magnification system packaged up into a console usually styled to look something like a small portable TV of the day, and different models had built-in battery lights, or collected ambient light with a mirror. The screen was usually a large rectangular lens about 100mm(4″) diagonal.

[Kris]’s Vistarama slide viewer came via eBay. It’s not the smallest of viewers, other models folded their light paths with mirrors, however the extra space meant that the Arduino fit easily. The OLED was placed where the slide would go, and its display appeared at just the right magnification and brightness. Job done, and looking rather stylish!

We’ve not featured a slide viewer before here at Hackaday, though we did recently feature a similar hack on an Ikea toy projector. We have however featured more than one digital conversion on a classic slide projector using LCD screens in place of the slide.

Via Robots and Dinosaurs makerspace, Sydney.