https://community.element14.com/challenges-projects/project14/spring-clean/Do you have a half-finished project or a project which did not end up working? This is your excuse to finish it! Take an old project and complete it to be in with a chance of winning.en-USTelligent Community 12https://community.element14.com/challenges-projects/project14/spring-clean/b/spring-clean-projects-2026/posts/spring-clean-project---making-a-case-for-my-nes-cloneMon, 18 May 2026 01:28:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:e5eabde3-b6a4-4321-a29a-e16c175d6efddang74I have one project that was really rewarding from an electronics perspective but really underwhelming in the presentation department. I am hoping that this Spring Clean challenge will provide the incentive to remedy this. Eight years back I bought something called the Retro Port Adapter. I guess it can be described as an after-market accessory for the Super Nintendo that allows it to play original NES games. This objective is stated concisely enough on the product label as: PLAY NES GAMES ON YOUR SNES. In terms of the picture below, imagine the bottom part of the adapter plugging directly into the Super Nintendo's cartridge slot. The top part of the adapter, meanwhile, receives an original NES game cartridge. At some stage I decided to pop the cover and try to understand its inner workings. The short version of the story is that the Retro Port Adapter contains an NES-on-a-chip, which squeezes all the functionality of the original NES onto a single device. The Super Nintendo itself, doesn't do much other than read from its controllers and write to a few addresses that are decoded on the Retro Port Adapter. In fact the Super Nintendo does not produce the video signal. The video instead comes from a TRRS (tip-ring-ring-sleeve) jack on the side of the Retro Port Adapter. For the long version of the story you can listen to this long-drawn out explanation from a younger and less jaded version of me. Remember, I said this was optional. https://youtu.be/nGa7X3JsHBk Once I had learned the secrets under the hood, it occurred to me that the Retro Port Adapter could be transformed into a stand-alone NES clone and that is what I set out to do. My approach in this endeavor is illustrated in the diagram below. The key facets of the design are as follows: 1 a microcontroller is required to carry out the functions originally performed by the Super Nintendo 2 the two NES controllers must be read out in a serial fashion just like in the original NES 3 the microcontroller acts as the master of the Super Nintendo cartridge bus 4 in its role as master, the microcontroller would require dedicated I/O for the 8-bit data-bus, read/write strobes, and select address lines 5 (after reading from the controllers) the microcontroller will write to the two holding registers that reside on the Retro Port Adapter For the microcontroller I used a little dev board called the Teensy++. The nice thing about this board is that its I/O support 5V logic which is great for projects that target retro electronics. Earlier I had said that this project was underwhelming when it came to presentation. Well, I was being nice. It is ugly and what's more it was always ugly. It was even an ugly baby. This is evident in the photo below that was taken in the initial prototype stages. That was the beginnings, but even after toiling away this is what I ended up with. And you know what? It is still ugly. At any rate, lets get acquainted with this Frankenstein monster. Blue Board this is the Retro Port Adapter without its plastic shell. The black clump conseels the infamous NES-On-a-Chip device Green Board this is a custom board that ties everything together. It includes two controllers and a site for the Teensy++ microcontroller board Teensy++ the Teensy++ resides on the underside of the Green Board. Its position can be worked out from the through-hole pin pattern in the photo above It's not all doom and gloom, though. There are some silver linings. For instance, those 22 AWG wires are so strong they serve as a support structure for the Retro Port Adapter PCB. The real positive though is that, ugly or not , this 'thing' actually worked. Here is another poorly produced video from 8 years back demonstrating functionality. https://youtu.be/Ng9SoVvtm0I This project proved to be a really good exercise in reverse engineering. Repurposing the product to make a stand-alone NES clone was very satisfying. However, its final form with two boards connected precariously together made it far from inviting. In the end the project was put in a drawer and all but forgotten. When the Spring Clean challenge was announced I wondered if this project could be revisited. Was there a way to bring it new life? At a bare minimum, I recognized that some form of enclosure was needed to house the electronics, and these are the objectives I set out: 1 a housing or container was needed to hide the electronics 2 openings are required in the housing for the game controllers, power cable and AV cable 3 a good game should be chosen to be permanently installed (after all, those 22 AWG wires aren't rigid enough to handle the repeated swapping of game carts) 4 make it fun and appealing After some thought I settled on Maniac Mansion, which is one of my favorite games from my younger years. From there I came up with tentacle. You see, Maniac Mansion contains a number of anthropomorphized tentacle characters including the green tentacle pictured below. I resolved then to print some kind of tentacle container. However, I had never worked on a 3D design before so I was both excited and a little nervous at the prospect. I installed Autodesk Fusion and went to work on the base. Since I don't have my own 3D printer I used a local service and here is the result. The printer used a 0.2mm nozzle and overall I was impressed with the build quality. It was done in PLA but the 3D print lines were less pronounced than examples I've seen in the past. You will notice that there are 4 posts. These were added to elevate the green board. Well, that was the plan anyway, but in my haste I accidentally added them when the model was flipped. This caused their XY positions to be mirrored, so it was back to the drawing board. This is the revised base in Fusion: I designed nut-traps on both sides of the base. The ones on the reverse side, which are not visible in this view, are used to fasten the board and secure the base to the shell. The shell itself is pictured below: Unlike the blob-like shape of the first iteration, this time I opted for a simpler geometric shape. This is what the new base looked like upon receipt: Overall I was happy with the results. However, I made an amateur mistake and it cost me my posts. In the design process when I was extruding the posts I forgot to select the option to join them to the main body. As a consequence they were not included when I exported to STL. Here is how the shell turned out: I had become accustomed to seeing so many 3D printed parts in bland colors, so seeing this shell in a bright and bold pink was a revelation. My first challenge was dealing with the missing posts. I figured that 1cm nylon spacers would serve as a suitable substitute, but finding them in a brick and mortar store is another matter altogether. In the end I bought some reusable straws and cut them to length. I filled the straws with rolled paper to tighten the space around screw. The effects of gravity caused some of the holes in the shell to deform slightly. It was necessary, for instance to file down the hole for the toggle switch and installing the mini USB power cable took a bit of elbow grease. From there it didn't take too long to install the board into the housing. A quick functional test revealed that the game was working and I played just long enough to end up in the dungeon. Originally I had considered painting the tentacle's markings but the pink glossy finish gave me second thoughts. At some point I decided that felt would do the job and also provide a bit of depth. The white bottle in the picture below is Aleene's Felt & Foam Tacky Glue It was good for bonding fabric to fabric and fabric to PLA. I wasn't quite done with the felt. I used some to make a lid and give the impression that the tentacle was severed cleanly with a bone saw. Yes, I know that tentacles are invertebrates. Anyway - let's see it in action. https://youtu.be/ktG75zNXIjQ Initially when the Spring Clean challenge was announced I didn't think I had a suitable project on the back burner. Eventually though, I remembered this diamond in the rough from 8 years back. In the end I am so glad I participated in this challenge. While it could be said all I did was make a bucket with velvet patches, the experience meant much more to me than that. It connected me to the past, first by revisiting an 8 year old project, and then again when I played the game itself. The challenge was also a learning experience in that it served as an introduction to 3D design and now I know just enough Autodesk Fusion to be dangerous. Finally, thank you element14. The various design challenges you put forth offer participants an opportunity to grow and refine their skillsets, and this one was especially enriching for me.https://community.element14.com/challenges-projects/project14/spring-clean/m/managed-videos/151329Mon, 18 May 2026 01:16:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:1df285c9-f34c-440d-8a9e-6c5ee1e0ee8belement14 CommunityI made a 3D printed housing for an old project... and yes it's shaped as a tentacle.https://community.element14.com/challenges-projects/project14/spring-clean/m/managed-videos/151328Mon, 18 May 2026 01:14:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:b2640d32-a397-4a7d-9b3a-ac24ff75eb5cdang74In 2018 I converted a Retro Port Adapter into stand-alone NES clone. From the vaults, this video shows the moment when everything came together.https://community.element14.com/challenges-projects/project14/spring-clean/m/managed-videos/151327Mon, 18 May 2026 01:12:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:8de4ebd7-984e-4b6e-8d05-3a294667fb5bdang74This video is made up from some footage I shot in 2018. In this video I explain the inner workings of the Retro Port Adapter, a device that allows you to play NES games on your Super Nintendo.https://community.element14.com/challenges-projects/project14/spring-clean/m/managed-videos/151322Fri, 15 May 2026 08:28:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:028c9ae7-9223-4845-812b-af4c33476130Samuel.https://community.element14.com/challenges-projects/project14/spring-clean/b/spring-clean-projects-2026/posts/alex---search-and-rescue-robotFri, 15 May 2026 08:28:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:1c0bf131-b284-410a-bcb0-60bdb313e731Samuel.Introduction: Search-and-rescue operations are among the most difficult yet important applications of robotics engineering. In disasters like building collapses, industrial accidents, nuclear incidents, and so on, the ability to quickly find survivors, assess dangerous environments, and deliver needed supplies without putting people in danger is paramount. Tele-operated ground robots meet this need directly, letting operators navigate dangerous, GPS-denied areas with little situational awareness and under a lot of time pressure. These challenges are reflected in the mission scenario underpinning this project. Alex, the tele-operated rescue robot developed, is designed to navigate its environment under remote control via a dual-operator architecture, locating items via floor-mounted colour markers, retrieving them using a robotic arm, and delivering them to another location. A 360° LIDAR sensor provides continuous spatial awareness to support real-time operator decision-making and post-mission mapping. Robots like the iRobot PackBot and Quince have been deployed in active conflict zones and nuclear disaster sites, respectively, performing precisely this kind of remote sensing, manipulation, and environmental mapping under conditions hostile to human entry. Alex is designed and evaluated against the same functional requirements that define these platforms. System Architecture: Alex involves 11 devices, namely the Arduino Mega, Raspberry Pi, DC Motors, Colour Sensor, Motor Shield, Arm Servos, E-stop Button, LiDAR and three laptops for the teleoperator. Figure below shows the system architecture of our Alex robot, which shows all components of Alex and its connections. Hardware Design: Firmware Design: High-Level Algorithm: Hardware Configuration: Timers and pins setup so that the Arduino can properly control the robot Initialisation: Synchronise hardware and establish safety protocols. Receive User Command: Listen for operator input using USART. Carry Out Command: Process input, check if e-stop is active (if it is, the packet will be disregarded), transmit data packets, and execute hardware movement. Loop: Repeat steps 2 and 3 until objective is met Further Breakdown Hardware Configuration Communications (USART): Configured to a 9600 baud rate to ensure stable, lowerror serial communication with the Raspberry Pi. Safety (E-Stop): The designated E-Stop pin is configured to trigger a hardware interrupt on any logical change. The Interrupt Service Routine (ISR) implements software debouncing to prevent multiple triggers from a single press. The logic evaluates both the system state and the physical button state: if the E-stop is disabled and the button is depressed, it halts the system if enabled and released, it resumes operation. Colour Sensor (TCS3200): The output frequency is scaled to 20% to keep the signal within the Nyquist-equivalent sampling limits of the microcontroller. External Interrupt 1 (INT1) is initialised to increment a variable on every logical change. Over a 100ms window, this yields discrete frequency values for the red, green, and blue color channels. Robotic Arm (Servos): The servo pins are initialised as outputs, and Timer 5 is configured for Output Compare Match. Instead of relying on four separate timers, the Timer 5 ISR is programmed as a sequential state machine to "daisy-chain" control pulses. The ISR toggles the respective PORTK pins and dynamically recalculates the next interrupt interval to deliver precise pulse widths. A final idle phase is calculated to maintain a stable 20ms refresh frame. Locomotion (Motors): The L293D motor driver shield is configured utilising the standard AFMotor library. 2. Initialisation Interrupt Activation: Global interrupts are initialized via the sei() command. Individual hardware components are subsequently activated by configuring their respective control registers. Specifically, the EIMSK register is modified to enable both the INT0 (E-Stop) and INT1 (Colour Sensor) external interrupts, while the TIMSK5 register is updated to activate the Timer 5 servo interrupts. Crucially, the hardware-level configuration of INT0 guarantees that the E-Stop mechanism will instantly preempt the main program loop under any condition. Default Hardware States: The servos are initialized to safe, pre-calculated base angles to prevent erratic, unpredictable movements upon startup. The default motor speed is set to a duty cycle of 78.4% via the AFMotor library. Sensor Start, GUI Update and Handshake will be discussed under Software Design. 3. Receive User Command To prevent unpredictable hardware behavior, the firmware uses a strict, structured communication protocol to ensure data integrity between the Raspberry Pi and the Arduino. Packet Polling: The Arduino continuously polls the UART receive buffer, ignoring all incoming bytes until it detects the specific two-byte magic header (0xDE, 0xAD). Payload Retrieval: Upon verifying the magic bytes, the Arduino reads the subsequent 101 bytes (comprising a 100-byte payload and a 1-byte checksum). Data Verification: The Arduino computes a local checksum by performing a bitwise XOR across all payload bytes. If this computed value differs from the received checksum byte, the system assumes bit-corruption occurred during transmission and discards the entire packet. Carry Out Command The complete command processing workflow on the Raspberry Pi is detailed in Section 6. Loop Repeat steps 3 to 4 until the objective is met. Software Design High-Level Software Algorithm Flowchart for Arm Control High-Level Software Algorithm Flowchart for Color Sensor 1. Initialisation Baud Rate Synchronisation: The Raspberry Pi explicitly locks the serial baud rate at 9600 to match the Arduino’s configuration, ensuring stable, error-free UART telemetry between the microcontrollers. Handshake Protocol: The Pi enters a TCP listening state, waiting for the secondary operator terminal to connect and bind to local port 65432. Sensor Start (LiDAR): The Pi initialises the LiDAR module via a USB/Serial interface. The SLAM algorithm takes control of the data stream, resetting the occupancy grid and localizing the robot's physical origin to (0,0). GUI Update: The SLAM interface immediately renders the initial LiDAR scan to the operator's display, establishing situational awareness prior to any locomotion. 2. Receive User Command (The full list of inputs are provided below) E-Stop Safety Architecture (“e”): The system continuously monitors for software safety triggers. When “e” command is sent, a two-step halt sequence occurs: Pi (High-Level): Instantly updates its global state to block any new movement commands from being queued, while simultaneously transmitting a priority halt packet to the Arduino. Arduino (Low-Level): Upon receipt, the Arduino immediately sets its internal E-Stop state to active, stopping all motor and servo PWM signals. It ignores all subsequent movement packets and sends an acknowledgment packet back to the Pi. Chassis Locomotion (“w”, “a”, “s”, “d”): Directional keys are passed with a duration parameter. Use case: [value]. For example, “w 5000” makes the robot move forward for 5000 milliseconds Velocity Control (“v”): Adjusts the global chassis speed using an 8-bit parameter Use case: [value]. e.g. “v 255” makes the robot move at max speed The effective duty cycle percentage is calculated via 255 × 100% and implemented using the AFMotor library on the Arduino. Firmware-level limiters automatically cap values exceeding 255. Arm Manipulation (“sh”, “b”, “el”, “gr”): Controls the shoulder, base, elbow, and gripper respectively. (This process will be elaborated in the next section) Use case: [value]. e.g. “b 180” makes the base turn toward the 180° direction. Software limiters restrict the inputs to valid physical ranges, preventing hardware strain and self-collision. Colour Detection (“c”): Triggers the TCS3200 sensor to process an RGB frequency reading of the floor marker. (This process will be elaborated in the next section) Complete and functional project video ( h ttps://youtu.be/QglzhW2I7To ) 2 most important lessons learned in this project: The Challenge of Concurrent Stream Management: During the integration phase, I realised that relying on sequential, blocking execution is entirely insufficient for a complex, dual-controller robotic system. My Raspberry Pi was tasked with managing high-level processing, which included handling asynchronous data such as LiDAR point clouds, highly restricted camera frames, and real-time commands from two separate operators simultaneously. Relying on blocking code created severe bottlenecks. For instance, a delay in one process such as waiting to fetch one of my limited visual frames would "freeze" the robot. Because the final mission has a strict 8-minute time limit and requires immediate reaction to the physical E-Stop, these freezes were unacceptable for safety and performance risks. This highlighted the absolute necessity of non-blocking, eventdriven programming and prioritised hardware interrupts in real-time embedded systems. The Criticality of Pre-Implementation Architecture: Throughout this project, I learned that the cost and complexity of design changes increase exponentially as integration progresses. My initial ad-hoc software development led to fractured logic that was highly prone to failure and incredibly time-consuming to debug during my trial runs. Furthermore, assembling the hardware without prior spatial planning caused compounding mechanical issues. Because I had to precisely manipulate an 8x5x5cm medpak without touching high walls, sensor visibility was paramount. I repeatedly had to disassemble the chassis to relocate the camera for better gripper visibility and shift towering components that were obstructing the LiDAR's field of view. Ultimately, I learned that rigorous pre-implementation planning, mapping out both software architecture and a physical 3D layout is non-negotiable to prevent wasting critical testing phases on structural rebuilds. 2 greatest mistakes: Physical Integration & LiDAR Field of View (FoV): One of my primary hardware oversights was the initial mounting position of my 360° LiDAR unit. I placed the sensor where chassis wiring and structural supports partially obstructed its laser sweep. Because a core mission objective was submitting an accurate, hand-drawn map of the unknown base layout, this oversight was critically damaging. The obstructions created blind spots in my SLAM mapping, causing the robot to misinterpret its distance from walls or fail to detect them entirely, risking heavy penalties for environmental collisions. Moving forward, I implemented a strict "clearance-first" design rule for the third layer of the chassis, ensuring the sensor’s optical path remained entirely unobstructed by objects. Low-Level Resource Contention (Timer Conflicts): I initially failed to maintain a comprehensive Timer Resource Map. When I began testing the locomotion system, I realised too late that the PWM signals driving my four independent DC motors via the L293D shield were competing for the same hardware timers used by the 4-DoF arm servos. This conflict rendered some motors completely unresponsive to operator commands. This mistake taught me a vital lesson: bare-metal programming requires a deep, uncompromising understanding of the microcontroller’s datasheet. Peripheral and timer allocation must be planned as strictly as the software logic itself to prevent hardware-level interrupt clashing. Continuation of half-complete project: The Hardware Trap and Loss of Momentum Building a reliable physical foundation for a robotics platform is rarely as straightforward as writing code. The process of sourcing compatible equipment is inherently tedious; in robotics, a single mismatched component can stall the entire build. By the time the compatible hardware actually arrived, my initial excitement had likely faded. The project became a literal box of parts, sitting half-complete while I waited on shipping and logistics, sapping my momentum before the complex assembly even began. The Intimidation of the System Architecture The Intimidation of the System Architecture The core of my project inertia stems directly from how daunting the integration phase is. Looking at the high level system architecture of the final system, I realize I'm not just building one thing; I am building distinct sub-systems that must communicate flawlessly. I had to figure out how to make a Raspberry Pi, which handles the high level algorithm for software design like arm control and color detection, communicate with an Arduino, which manages the high level algorithm for the firmware design. Developing the communication protocol to handle the format of messages and responses between these microcontrollers is often the most complex and failure-prone part of a robotics project. It is incredibly common to delay starting because mapping out this protocol feels overwhelming.Search and Rescue Robotlidarcolour sensorraspberry pirobotic arm