Update: You can follow the discussion of this article around the web on HN, Adafruit, Hackaday, and Hackster.io!

This article explores the research and development journey behind my new sensor system, OptiGap, a key component of my PhD research. I’m writing this in a storytelling format to offer insights into my decision-making process and the evolution leading to the final implementation. It should hopefully provide a glimpse into the sometimes-shrouded world of PhD research and may appeal to those curious about the process. For a deeper dive into technical specifics, simulations, and existing research on this subject, my dissertation is available online here.

What does it do?

In very general terms, this sensor is basically a rope that if bent can tell you where along its length you bent it. The fancy term for that is “bend localization.”

OptiGap’s application is mainly within the realm of soft robotics, which typically involves compliant (or ‘squishy’) systems, where the use of traditional sensors is often not practical. The name OptiGap, a fusion of “optical” and “gap,” reflects its core principle of utilizing air gaps within flexible optical light pipes to generate coded patterns essential for bend localization.

How the OptiGap Sensor System Started

The idea for OptiGap came about while I was experimenting with light transmission through various light pipes (optical cables) for use as a bend detection sensor. I was initially trying to see how I could effectively “slow down” light through the fiber…a seemingly straightforward task, right?

During this process, I attached a section of clear 3D printer filament (1.75mm TPU) to a piece of tape measure for an experiment and incidentally discovered that when I bent the tape measure (and filament) at the spot where the electrical tape was attached, there was a significant drop in light transmission. I hypothesized that this was because the sticky residue of the electrical tape was causing the filament to stretch, which in turn reduced the light transmission.

To verify this hypothesis, I attached a longer piece of TPU to a tape measure and began bending it at various points to observe how light transmission would change.

I wrote a small Linux I2C driver for the VL53L0X ToF sensor to run on a Raspberry Pi and push the data to a socket using ZeroMQ. I then created a rough GUI in Python to pull the sensor data from the socket and visualize the light transmission data in realtime, shown in the GIF below, which very quickly validated my hypothesis. This validation marked the “Eureka!” moment that sparked the eventual development of the OptiGap sensor.

The OptiGap Realization

I realized that since I could control where the light was being attenuated, I could use this to encode information about the position of the bend on the sensor. Using electrical tape was not a practical solution, so I started looking for a more reliable and consistent way to create these attenuations. This led me to the idea of cutting the filament and then reattaching it together using a flexible rubber (silicone) sleeve, leaving a small air gap, as shown in the image below.

The main working principle of the air gap is that translation and/or rotation of one light pipe face relative to the other changes the fraction of light transmitted across the gap. The greater the bend angle, the more light escapes across the gap. The resulting change in intensity of the optical signal can then be correlated with known patterns for use as a sensor.

The Big Idea

I then proceeded to test this idea by creating multiple air gaps in a row and bending the filament to measure the attenuation.

As depicted in the GIF below, the optical intensity decreases at each air gap, with a more noticeable decrease as the bend angle increases. This initial experimentation served as proof of concept, demonstrating the feasibility of the idea. It led to the formulation of my final hypothesis of utilizing a pattern of these air gaps to encode information regarding the sensor’s bending and employing a naive Bayes classifier on a microcontroller to decode the bend location.

This concept resembles the functionality of a linear encoder. Linear encoders gauge an object’s linear movement, typically comprising a slider rail with a coded scale akin to a measuring ruler and a sensing head that moves across this scale to read it. Linear (absolute) encoders emit a distinct code at each position, ensuring consistent identification of displacement.

The OptiGap system, functioning like an absolute encoder, would encode absolute positions using patterns of bend-sensitive air gaps along parallel light pipes, effectively serving as a singular fiber optic sensor.

Encoding the Bend Location using Inverse Gray Code

Absolute encoders commonly employ Gray code, a binary system where two successive values differ in only one bit. This property allows for various applications, including error checking. However, Gray code isn’t optimal for the OptiGap sensor system. Here, we aim for consecutive values to differ by the maximum number of bits to facilitate easier differentiation. This necessity gave rise to Inverse Gray code.

Inverse Gray code is a binary code where two successive values differ by the maximum (n-1) number of bits. To implement this, I simply create cuts in the filament wherever there’s a “1” in the Inverse Gray code sequence. This approach can scale to any bit number. For the prototype, I utilized 3 bits, providing 8 possible positions.

Visualization of the OptiGap Sensor System

The illustration below depicts the signal patterns of the OptiGap sensor system for each bend position using three fibers. By employing a naive Bayes classifier, the sensor system can discern bend positions based on signal patterns. The third graph represents actual sensor data from the prototype system, utilized for training the classifier on the microcontroller.

The OptiGap Prototype

I proceeded to construct a prototype of the OptiGap sensor system, utilizing 3 strands of clear TPU 3D printer filament, each featuring a distinct pattern of air gaps. The image below showcases the filament just before cutting, with the cut pattern indicated on a piece of tape.

For the prototype, I employed a commercial 3:1 fiber optic coupler to merge the light from the 3 strands into a single fiber optic cable, resulting in the completion of the sensor prototype, as depicted below.

This marked the final phase of validating the hypothesis and operational theory behind the OptiGap sensor.

Reducing the Physical Size

The initial prototype proved to be large and bulky, primarily due to the size of the 3D printer filament used. Drawing from previous experience, I recognized that PMMA (plastic) optical fiber offered a smaller and more flexible alternative suitable for this application. Consequently, I assessed 500, 750, and 1000 micron unjacketed PMMA optical fibers from Industrial Fiber Optics, Inc. for the sensor strands, resulting in a significant reduction in sensor size.

I conducted tests on all three types of fibers to evaluate their light transmission and flexibility. Among them, the 500 micron fiber emerged as the optimal choice overall, although all three exhibited sufficient flexibility for this application.

Reducing the Optical Transceiver Complexity

I decided to switch from using the complex VL53L0X ToF sensor to a simple photodiode and IR LED setup to reduce the complexity of the system and to increase modularity. This also allowed me to use a  microcontroller to read the sensor data, which was a significant improvement over the initial prototype.

I then created a demo system for the sensor based around an STM32 microcontroller and a photodiode/IR LED setup.

Realtime Machine Learning on a Microcontroller

The final stage in developing the OptiGap sensor system involved integrating a naive Bayes classifier onto the STM32 microcontroller to decode the bend location from the sensor data. I opted for a naive Bayes classifier due to its efficiency compared to if-statements or lookup tables, its capability to handle new or previously unseen data, and its potential for increased accuracy by considering relationships between multiple input variables.

Implementing the naive Bayes classifier proved to be relatively straightforward. This classifier is a probabilistic model based on applying Bayes’ theorem to determine how a measurement can be assigned to a particular class, with the class representing the bend location in this context. I utilized the Arm CMSIS-DSP library for the classifier implementation.

Fitting the Sensor Data

The initial step in integrating the classifier was to fit the sensor data to a Gaussian distribution for each air gap pattern. To expedite this process, I developed a Python GUI for rapid labeling and fitting of the data using GNB (Gaussian Naive Bayes) from the scikit-learn library.

I later improved this UI to be more general and to allow for more complex data fitting.

The probabilities for each class were computed and saved as a header for use on the microcontroller.

Filtering the Sensor Data

To enhance the accuracy of the classifier, I implemented a two-stage filtering process on the STM32 . The initial stage involved a basic moving average filter, followed by a Kalman filter in the second stage.

The OptiGap Sensor System Demo

The GIFs provided below illustrate various stages of the OptiGap sensor system, encompassing assembly and the operational demonstration of the final sensor system.

System Overview

Assembly of an OptiGap Sensor using TPU Filament

Attenuation of Light through the OptiGap Sensor

Fitting of the Sensor Data

Segment Classification using PMMA Optical Fiber

Segment Classification using TPU Filament

Underwater Operation

OptiGap Design Specifications

Key Properties & Parameters

Material Recommendations

Next Steps

I’ve made significant progress on the OptiGap system beyond what’s documented here, including its integration into another modular actuation and sensing system I developed called EneGate.

This has involved custom PCB design and systems integration, detailed in my dissertation. Additionally, I’ve prototyped miniature PCB versions of the optics to interface with the PCBs for the EneGate system.

I’ve also validated OptiGap on a real-world soft robotic system, with full details set to be presented in an upcoming RoboSoft paper titled “Embedded Optical Waveguide Sensors for Dynamic Behavior Monitoring in Twisted-Beam Structures.“

Commercialization

There’s an ongoing commercialization aspect to this research as well. Feel free to reach out if you’re interested in further details.

That’s it for now!

I don’t want to make this too long so I’ll end here. I hope this provided some insight into the research and development process involved in something like this. If you have any questions or would like to learn more, don’t hesitate to contact me!

The post R&D Case Study: Developing the OptiGap Sensor System appeared first on Paul Bupe Jr, PhD.

I’ve been designing a 4-layer PCB for a product for a few months now and I finally got to the stage of assembling the prototype after the PCB and components arrived. Most of the passive components I used were 0603 surface mount parts so reflow soldering was the only viable option (if I wanted to maintain my sanity).

Since I don’t have a proper reflow oven, I decided to use the next best thing I own: No not my hot air rework station, a toaster oven!

There are, of course, plenty of guides and tutorials online for modifying a toaster oven for reflow soldering. They all involve a temperature PID loop to precisely control the heat profile for various solder types, components, etc,.

I really just wanted to see if I could just turn it on and see what happens. Spoiler Alert: It works.

I just preheated the toaster oven for a few minutes, stuck the PCB in there, and watched for the solder to start flowing. This took about 30 to 40 seconds. I wish there was more to this so I could do a more in-depth write-up but honestly that was it — nothing fancy and no precise timing or temperature profiles.

I gotta say, the final board is quite a beauty!

The Fine Print

Do this at your own risk! I did it because I’m just building a prototype and the final board will be professionally assembled. In addition, I know what I’m doing and I read the datasheets of all my critical components. You’ll notice that I did not put the electrolytic capacitor in the oven — I could not guarantee not to violate the very precise timings and temperatures specified in the datasheet. Also, please mind the fumes.

The post Reflow Soldering in Unmodified Toaster Oven? appeared first on Paul Bupe Jr, PhD.

Update: This article was featured on Hackaday.com and on SDP/SI’s “Featured People and Organizations” page.

Goose is a mobile autonomous robot I designed and built over 6 months in my spare time for a robotics competition. This was a fully custom and challenging build that tested my competence in electrical engineering, mechanical engineering, control systems, and computer science.

Instead of focusing heavily on the competition, the goal of this article is to briefly go through the system design process. I’ll touch on my various design choices and discuss how I chose to address some of the common issues in designing an autonomous robot. This is not a tutorial (those will be coming later) but more of a case study.

Competition and Results

The basic premise of the competition was to have an autonomous robot navigate a square arena (enclosed by four walls) and collect / sort  multi-colored cubes and balls. It had to avoid fixed obstacles and had a 3-minute time limit. The robot was also required to “orbit” around the center of the arena in a counterclockwise fashion while performing the aforementioned tasks.

Goose was in second place after the first round then suffered a catastrophic reverse polarity condition at my hands (thanks Murphy) prior to the second run. I made two critical mistakes:

1. I daisy-chained the power rail going to my two motor controllers instead of tying each directly to my power bus. This set me up for the upcoming cascading failure.
2. After being awake for over 24 hour I somehow reverse polarized the power rail going to my motor controllers, which destroyed them both.

Even without a second round run, Goose did well enough in the first round to finish fourth overall in the Open competition.

Hardware Design

The first hardware decision I made was selecting the type of drive system the robot would employ. Since the robot was constrained to a 9″ x 9″ x 11″ box, and once I realized that I was just building a glorified vacuum cleaner, my design ideas converged towards a very compact Wall-E type chassis.

Based on experience I chose a tracked differential drive system, i.e., non-holonomic like a tank. As a general rule you want to avoid using omnidirectional wheels an autonomous robot unless you have a localization system that gives you an accurate pose. Using a two-motor differential drive system allowed me to achieve a compact design by placing the geared motors in the rear and directly driving the tracks.

SDP/SI was gracious enough to provide me with the timing belts and pulleys I used in my custom drivebase (shown in the image above) so thanks to them! I also would not have been able to build this robot without the amazing engineering/manufacturing facilities at Georgia Southern University that have state of the art equipment (such as the waterjet and laser cutter I used) available to students.

Prototyping and Base Build

After getting a rough idea of the physical design of the robot I started prototyping using SolidWorks, my 3D printer, and a laser cutter. My prototyping workflow involved first sketching out parts on paper, creating them in SolidWorks, then 3D printing or laser cutting them as needed. In total I ended up creating around 232 SolidWorks parts by the end of the build.

The biggest issue I ran into was figuring out how to remove play from the shaft in the bearing. The inner race of the bearing would move when under tension which caused alignment issues with the belt. The shaft was anchored at one end only because there was no room to add a second bearing (even a sleeve bearing) on the outer plate end due to the competition size constraints.

I was able to overcome this issue by designing a sturdy bearing mount that I mounted on the inside of the bracket then added a smaller acrylic mount with a sleeve bearing on the outside. This, along with shortening the shaft, was able to remove any play from the shaft under tension. I also added a very small lip to the pulleys to prevent the belt from slipping. The final base used aluminum which was machined using a MAXIEM 1515 waterjet cutter.

The remaining parts were created using wood with the help of a laser cutter.

Electronics

The electronics subsystem of Goose utilized an architecture that I have been tweaking for my autonomous robot designs over many years. The main idea is to minimize the cost of failure by isolating as many systems as possible and using generalized interfaces to connect the systems, i.e., modularization. All the supply rails are also individually fused with on/off switches and indicators.

Some core safety features of my architecture include:

• Proper fusing for overcurrent protection.
• Crowbar circuits for overvoltage protection. Crowbar circuits require very careful design in order to avoid false triggers due to noise or a narrow operating band.
• High current ideal diodes for reverse polarity protection. I did not include this in Goose and of course suffered a competition ending reverse-polarity condition so I won’t skip it again!

All these concepts are nothing new in electronics but striking the right balance between complexity and functionality for any one particular application can be tricky, especially when creating an autonomous robot.

Even though this system did not contain any sensitive analog circuitry, I still isolated the noisy motor power rail from the rest of the circuitry, eventually tying everything together at a single point at the battery in the “star ground” configuration. It’s always important to have a good idea of the major current paths in your circuits so you can spot any potential issues like ground loops — this does not require advanced knowledge of mesh analysis!

Mainboard

I have made it a habit to always use soldered PCBs for my projects. While breadboards are useful in the very initial stages of prototyping, they should not be used for anything past initial testing and brainstorming — they are too unreliable and can be difficult to troubleshoot due to issues like intermittent connections. Depending on your level of experience most analog circuits can be designed using a SPICE simulator and some basic math.

I designed the board for GOOSE using a stripboard. Stripboards are easier to use than regular solderable PCBs for more complicated circuits because they have connected strips (thus the name) that you cut to break the circuit at a desired point. This means you don’t have to solder a lot of holes in order to make a power bus or run a signal to multiple pins. Just don’t forget to cut the traces or you’ll have a pretty bad day!

The board contained the 5V and 3.3V power rails rated up to 2.5A, two PWM MOSFET driver circuits, a logic level converter, 9 DoF IMU, and the Teensy microcontroller. There are also a few other assorted supporting components.

Cabling and Wiring Harnesses

One of the most important and necessary skills in robotics is being able to make cables and wiring harnesses that are custom to the robot. While the process can be tedious, it results in a more reliable and professional end product. I typically use 2.54mm JST-XH connectors and “Dupont” connectors for my wiring when working with prototype boards. There’s quite a lot behind the names of connectors so I encourage you to read this article which does a great job summarizing most of what you’ll need to know about crimpers and connectors. For high current applications I used regular spade connectors and Wago 221 connectors for creating power busses. You can get generic versions of these on eBay and similar sites.

When creating long runs on this project I cannibalized a CAT5 cable and crimped on my own connectors to the ends. This was especially ideal because the twisted pairs meant I could effectively run differential signals if needed.

The NASA Standard for Crimping, Interconnecting Cables, Harnesses, And Wiring is a great resource for learning from the pros. While most of the crimping tools they use cost in the hundreds of dollars on the low end, the information is still relevant and quite useful!

Processing Subsystem

I used two processing cores for Goose: a Teensy 3.2 (32 bit ARM Cortex-M4) microcontroller to handle all the deterministic logic, and a Debian-based Raspberry Pi 3B+ for the more heavy computational work dealing with mapping and image processing. The Raspberry Pi was running the Robot Operating System (ROS) and the Teensy communicated to the Pi via USB serial.

Running at 96 MHz, the Teensy was fast enough to process data from two quadrature encoders and perform real-time odometry calculations; run an AHRS fusion algorithm from a 9 DoF IMU at about 2.1 kHz; run multiple PID loops; monitor two ultrasonic sensors at a high refresh rate, and send all this data to the Pi at a baud rate of 500,000. I had several ROS nodes running on the Teensy which communicated to the ROS Master on the Pi. As an example, I used the handler below to process messages from the Pi to the Teensy and then command the setpoint of the PID controllers:

void process_velocities(const geometry_msgs::Twist& cmd_msg)
{
	double x = cmd_msg.linear.x;	// forward velocity
	double z = cmd_msg.angular.z;	// rotational velocity

	if (z == 0) { // going straight
		left_motor_setpoint = x * 60 / (PI*wheel_diameter);
		right_motor_setpoint = left_motor_setpoint;
	}
	else if (x == 0) // turning in place
	{
		left_motor_setpoint = z * track_width * 60 / (wheel_diameter* PI * 2);
		right_motor_setpoint = -left_motor_setpoint;
	}
	else 
	{
		left_motor_setpoint = x * 60 / (PI * wheel_diameter) - z * track_width * 60 / (wheel_diameter * PI * 2);
		right_motor_setpoint = x * 60 / (PI * wheel_diameter) + z * track_width * 60 / (wheel_diameter * PI * 2);
	}
} // process_velocities()

Handler used to process velocity messages from the Pi and command the PID setpoints

I initially considered and prototyped using a BeagleBone Black since it contains two deterministic 32-bit PRU processing cores that can be accessed from the Linux system but I found the development overhead not worth it for one person with limited time. I wrote a few articles based on that experience here, here, and here.

Localization and Navigation Subsystem

The competition rules required the robot to move in large circles for the duration of the run which meant I couldn’t use encoder-based dead reckoning; the act of turning introduces errors due to drift and slippage which would accumulate to unacceptable levels over the course of the 3 minute run.

To counter this issue, I took advantage of the fact that the arena was enclosed by four walls in a square to develop a navigation system that used encoder odometry, IMU feedback, and LiDAR point cloud data to effectively pinpoint the location of the robot at all times.

As shown in the figure above, the basic idea was to use a pre-made map of the environment and then use point cloud data from the LiDAR in addition to the pose esitmate from to localize using a particle filter algorithm. I created the map in Adobe Illustrator and then converted it to a pgm file for use in ROS.

Localization inside a square would be difficult using LiDAR only (since all corners look the same and corner matching would fail) so I incorporated the pose estimate generated by fusing the encoder odometry data and the 9 DoF IMU using an unscented Kalman filter. I used an unscented Kalman filter (as opposed to the extended Kalman filter) for handling the nonlinear data because it is generally more accurate and has less computational complexity since there’s no need to calculate the Jacobian matrix.

Side note:

I have written a paper that includes some experimentation on developing a computationally efficient 2D navigation algorithm (for a microcontroller-based autonomous robot) which I might revise and release when I have the time. The algorithm I developed had a time complexity of O(n). Below is a page from the paper showing part of my experimental setup and a mapping / vector generated by the algorithm. I used a TFmini short-range LiDAR module for these experiments.

Final Thoughts

This project was certainly fun and a lot of work! There’s so much more to this robot I haven’t even touched on in this article but for the sake of keeping it “brief” I will have to end it here.

If time permits I may write a separate article on each system of the robot along with any associated source code and hardware info; possibly a series on building an advanced autonomous robot. I would like to go into more details on the software side and the workflow I came up with for working easily with ROS on a Raspberry Pi and a Teensy microcontroller.

Let me know your thoughts on this build or if you’d like to see any tutorials based on what’s in this build or robotics in general!

The post Designing an Advanced Autonomous Robot: Goose appeared first on Paul Bupe Jr, PhD.

I recently had to design a 4-layer PCB and I finally decided to give KiCad another try (after hearing great things about version 5). I’ve known about KiCad for years and even tried it once a few years back but it never felt quite “there” yet. After spending a few months designing a 4-layer board I have to say it has certainly won me over.

I had to design a fairly complex PCB that included a switching supply, high currents, plenty of thermal vias, high frequency traces, and some mixed-signal work so I was really curious to see what KiCad could do.

One of the most useful features in my opinion is the ability to easily view an interactive 3D rendering of the board with no additional setup. The ability to hide the soldermask and view just the copper layer in the 3D view is a great sanity check on top of the DRC.

Another really really really great feature of KiCad is the ability to easily import any 3D model as an STL or wrl file and visually align and scale it to a footprint. This feature coupled with a site like 3D Content Central that allows you find 3D models from virtually any supplier for free makes accurate PCB design really stress free.

Another underrated KiCad “feature” I have come to love is just how easy it is to move or copy components around in the schematic editor without having to hold down a mouse button. I think this feature, coupled with the convenient shortcuts, saved me quite a bit of time.

Based on this experience I think I’ll definitely stick with KiCad for PCB design until the single license cost for Altium becomes more reasonable. Expect a few detailed KiCad tutorials from me in the near future!

The post 4-Layer PCB Design in KiCad 5: Quick Thoughts appeared first on Paul Bupe Jr, PhD.

Picking up from Part 2, the third and final part of the wood click gears with motor drive build covers the stepper motor drive. The gears ended up driving this really beautiful clock. Note that I did not build the clock, just the gears driving the hands.

This part of the build was fairly simple since it was just a matter of driving a stepper motor at a constant speed. I also included a switch to be able to reverse direction.

Block Diagram

The drive system is extremely simple as shown in the block diagram. I did not create a schematic for the build and just used the block diagram for reference instead. The circuit was powered by a standard 5V regulated wall charger.

Stepper Motor and Driver

Since the project didn’t require a large motor, I used the 28BYJ-48 stepper stepper motor with the ULN2003 driver. This is an extremely popular stepper/driver combination with a great deal of documentation available online.

ATtiny85 Microcontroller

I opted to use the ATtiny85 microcontroller since I only needed a few pins to control the stepper motor driver. The ATtiny85 has 5 usable I/O pins — I used 4 for the stepper driver and 1 for the forward/reverse switch. Lastly, it is largely Arduino compatible so many library work without modification.

Code

The code (included below) was fairly straightforward — there is nothing fancy happening and I used the AccelStepper library. It is able to run the motor more efficiently than the default Arduino stepper library and includes a half-stepping mode, which is recommended for this motor.

Here is a great tutorial on using the Arduino Uno to program the ATtiny85. As a side note on the tutorial, you can get away with programming it without using the capacitor. 

// Simple program to drive a stepper at a constant speed
// using an Attiny85
// Paul Bupe Jr

#include <AccelStepper.h>;

// Defining some useful constants
#define HALFSTEP 8
#define MINUTE_STEPS 1.13777
#define SECOND_STEPS 68.266
#define SECOND_STEPS 115

// Motor pin definitions
#define motorPin1  0     // IN1 on the ULN2003 driver 1
#define motorPin2  1     // IN2 on the ULN2003 driver 1
#define motorPin3  2     // IN3 on the ULN2003 driver 1
#define motorPin4  3     // IN4 on the ULN2003 driver 1

#define dirPin     4     // Input for Clock Direction

bool last_dir = HIGH;
float step_speed = SECOND_STEPS;

// Initialize the stepper library in half-stepping mode
AccelStepper stepper(HALFSTEP, motorPin1, motorPin3, motorPin2, motorPin4);

void setup()
{  
   pinMode(dirPin, INPUT);
   stepper.setMaxSpeed(1000); // Arbitrary max speed 
   stepper.setSpeed(step_speed);	
}

void loop()
{  
  int dir = digitalRead(dirPin); // Get direction from switch
    // Only executes if the direction changed
    if (last_dir != dir) {
      if (dir) {
        stepper.setSpeed(step_speed); // Clockwise
        last_dir = HIGH;
      } else {
        stepper.setSpeed(-(step_speed)); // Counter Clockwise
        last_dir = LOW;
      }
  }
   stepper.runSpeed();
}

Putting Everything Together

With all the parts in and program written, I did some quick prototyping just to make sure everything worked as expected.

I then designed a quick mount in SolidWorks and printed it out using my 3D printer.

Then it was just a matter of crimping a few wires and soldering everything together.

After that I tested everything out then mounted it on to the back of the gear assembly.

Finally a quick test with everything assembled and it was good to go!

The post Wood Clock Gears with Motor Drive – Part 3 of 3 appeared first on Paul Bupe Jr, PhD.

Cutting the Gears

Since I designed the gears in SolidWorks, it was just a matter of exporting them as .DXF files and cutting them out on a laser cutter. I used wood approximately .2in thick which was sturdy enough for my needs.

Gluing Everything Together

As shown in the drawing from  Part 1, the 10 teeth gear is physically coupled to the 40 teeth gear while the 12 and 36 teeth gears share the same shaft but are free spinning. The 12 teeth gear controls the minute hand while the 36 teeth gear controls the hour hand.

Gears glued together with bearings

The 36 teeth gear has a hollow tube with a .25in inner diameter through which the shaft from the 12 teeth gear (the minute hand) goes through. I used quick setting epoxy to glue everything together.

The 12 teeth gear will be directly coupled to the motor so I fit it with a .25in shaft. I also made a D cut into the shaft to help with the coupling to the stepper motor.

Assembled Build

The post Wood Clock Gears with Motor Drive – Part 2 of 3 appeared first on Paul Bupe Jr, PhD.

I was asked to design and build the gear and drive mechanism for a 6 foot clock. The clock had an hour and a minute hand and needed to move in both the clockwise and anti-clockwise direction. This was not a “realtime clock” and needed to move visibly fast.

I decided to use wood clock gears with a motor drive for the sake of simplicity. This build was definitely more out of my comfort zone than usual but proved to be a fun and educational experience. Part 1  goes over the design of the gears. Part 2 will cover the physical build and Part 3 the electrical design and final build.

Preliminary Design

The design called for a minute and hour hand so the target gear ratio was 1:12 (since it’s a 12 hour clock). A clock requires the output shafts to be aligned, meaning I needed to create a compound gear configuration of four gears with two sharing a shaft each. The shaft spacing between each gearset needs to be the same. I chose to use spur gears since they are the most appropriate for my design and are also very easy to manufacture.

Calculating Gear Ratios

I set the minimum number of teeth to 10 since I only wanted to use four gears and based on the scale of the design. This made the gear ratio 10:120 (which is still the same). I then multiplied 10 by the square root of 12 (since that’s the gear ratio I’m targeting for each) to yield a new compound gear ratio of 10:35:120, which can be represented as 10:35 and 35:120.

Because I didn’t want to deal with a 120 teeth wooden gear, I needed to find a common denominator with which to divide the second set of gears. I bumped up the 35 to 36 and divided the right side by 3 to yield a final result of 10:36 and 12:40. This yields a gear ratio of 1:12

Gear Design

Up to this point I had the following information:

• The smallest gear has 10 teeth.
• Both gear pairs needed to have the same center distance (C).
• I wanted the pitch diameter (the effective diameter at which two gears mate) of the smallest gear to be around 1.5 inches.

The following image from Groschopp is a useful reference for gear terms and meanings.

The most important value I had to calculate was the module (m) of the gears. The module is the ratio of the pitch diameter (d) to the number of teeth (N):

Two gears must have the same module in order to properly mate. With a pitch diameter of 1.5 and 10 teeth, the module of the first gear is . Using the module formula, the pitch diameter of the second gear has to be . The center distance, C, is given by

which evaluates to . Using this information and the fact that the diametral pitch is the inverse of the module, the rest of the gears were calculated and designed in SolidWorks. In the final design I ended up increasing the pitch diameter to 1.52in.

Notes

At this point I’m fairly happy with the design. Since I’m designing wood clock gears I needed to make sure everything was scaled large enough to handle the stresses of the clock hands. Unfortunately I don’t know just how heavy the clock hands will be so the design assumes “reasonable worst case” scenarios.

The post Wood Clock Gears with Motor Drive – Part 1 of 3 appeared first on Paul Bupe Jr, PhD.

ModBot is a simple robotics platform created for testing sensors, algorithms, vision systems, and everything else in between. I designed this platform with modularity in mind (thus the name) which requires the compartmentalization of behaviors and functions into discrete and, ideally, interchangeable modules. Since this is an experimental platform I opted not tie it to ROS (even though it still uses a Linux environment so ROS can be used) and created a very simple ASCII protocol for communication between modules. Lastly, I added teleoperation capabilities using a PlayStation DualShock 4 controller.

Robotics Platform Block Diagram and Design

The base is the fairly standard four-wheel differential drive design. A Raspberry Pi controls the motors via a dedicated Arduino Nano microcontroller that has motion profiles/velocity curves for each motor.

I utilized standard sockets and connectors so that controllers and other components could be swapped out without full disassembly of the robot. Notably, I used RJ45 Keystone jacks so that I can use standard Cat 5 cables as module interconnects. Multiple microcontrollers can be added to the system using the I2C protocol I created for communication.

All the core components of this robotics platform are kept under the upper deck, which is used to hold whatever component or sensor is being tested. The ports for the Raspberry Pi and other components are oriented such that cables can be plugged in or removed without removing the cover.

Serial Communication Protocol

To help facilitate modularity, I created a simple serial protocol to abstract the transfer of data between modules.

Why Create a Custom Protocol?

As I started building more complex systems with multiple “brains” working together (Raspberry Pis, BeagleBones, and Arduinos), I founding myself needing a simple protocol that could be used to more easily facilitate communication to all these controllers over I2C. Over various projects I standardized formalized the following protocol.

There are a lot of full-featured and extensive protocols and libraries out there (Firmata being at the top) and this does not attempt to replace or compete with those. It’s a simple single-purpose protocol with the sole focus of use for simple robotic systems with no overhead or fancy features.

Robotics Platform Communication Protocol

This I2C protocol is designed to be simple, human-readable, and is suitable for transmission over a serial bus. All data are passed as ASCII characters between 0x24 (36) and 0x7D (125). The protocol is simple enough that it can be debugged without any special decoding as show in the screenshot from my oscilloscope below.

This is just a basic overview and not meant to be full documentation of the protocol.

Packet Structure

<START><SRC_ADDRESS><DST_ADDRESS><ACTION><COMMAND><DATA><END><CHECKSUM>

• The START byte is ASCII “{” (123 decimal, 0x7B).
• The SRC_ADDRESS byte is any value from 64 to 95 decimal (0x40 to 0x5F, ASCII “@” to “_”).
• The DST_ADDRESS byte is any value from 64 to 95 decimal (0x40 to 0x5F, ASCII “@” to “_”).
• The ACTION byte is an ASCII “?” for GET and ASCII “$” for SET.
• The COMMAND bytes are three characters.
• The DATA bytes are variable length and are described in the Data section.
• The END byte is ASCII “}” (125 decimal, 0x7D).
• The CHECKSUM is calculated by subtracting 32 from all the characters in the packet (excluding the start and end bytes) and summing them. The modulo 95 of this value is then calculated and 32 is added back to that value.

Checksum Calculation

int calculate_checksum(String packet) {
   int sum = 0;
   int c = packet.length();
   for (int i = 0; i < c; i++) { sum += packet[i] - 32;}
   return (sum % 95) + 32;
}

Example Commands

The available commands for this revision are listed in the table below.

Example MTR GET Command and Response

MTR GET command. This packet requests the speed of motor number 2.

{@e?MTR02}X

MTR GET response. This packet returns the speed of motor number 2.

{e@?MTR02+078}C

Teleoperation Test Run

Here’s a short clip of me testing the motion profiles and mixing of the inputs from the controller joystick. As you can probably tell there was still a bit of tweaking to be done when I took this video but overall the robotics platform was quite responsive.

The post ModBot: A Modular Robotics Test Platform appeared first on Paul Bupe Jr, PhD.

Amplifier Specifications

The full specs for this amplifier are available on the seller page but the general specs are:

• Power output (w/ 36 VDC power supply): 100W x 2 (6 ohms, THD 10%), 99W x 2 (6 ohms, THD 1%)
• Frequency response: 20 to 20,000 Hz
• Minimum impedance: 6 ohms
• Fixed gain settings: 24 dB, 25 dB, 26 dB

Chassis Design

I designed the chassis as a typical rectangular design using SolidWorks. The main design feature is that I added some slots for ventilation on two sides. Since this amp was purposed for desktop use, I opted to remove the fan and use passive cooling. Rodney Bryant did an awesome job of bringing my design to life! Here are a few pictures he took while building the chassis:

Electrical Design

The wiring for this build was fairly straightforward, mostly switches and such. First, I opted to use a single 3.5mm input instead of an RCA inputs since. I used an external power supply and placed a resettable fuse on the positive power rail. I then wired three switches to the amp: a main power switch in the rear, a standby switch, and a mute switch. Since I opted for passive cooling, I removed the fan and wired an LED to the fan connector.

Noise Floor

The main issue I encountered was the high noise floor (loud humming when nothing is connected and even when something is connected and is at low volume). I lost the shielding benefits presented by a metal chassis since this chassis was made out of wood, .

Because I was using a 3.5mm input, I had to solder some connectors onto the board instead of using the already present RCA connectors. The noise floor was drastically reduced when I connected an input to the RCA jacks as opposed to my 3.5mm input. This at least narrowed down the issue to my wiring. I tried the usual recommendations (shorter wire runs, shielded cables, twisted pairs) but nothing seemed to work.

Eventually I realized that in all my testing I had the ground from the 3.5mm input connected to the volume potentiometer and then from there to the amplifier. Instead, I needed to connect the ground directly from the input to the amplifier, not the potentiometer. This design is closer to the “star ground” technique where all the grounds are tied to a central point. Making this simple wiring change immediately eliminated the high noise floor and made the amplifier usable.

Volume Control

The volume control knob used in the initial design was a dual 50K “audio taper” potentiometer. Volume control potentiometers must have a logarithmic response because the human ear doesn’t perceive changes in loudness in a linear fashion. Here is a great article about the nonlinearity of human hearing.

I discovered that all the potentiometers I ordered (first from Amazon then from Mouser) were very flimsy and also introduced some scratching noises (they were all graphite pots) sometimes when switching. This was the opposite of the smooth and heavy feel I wanted and why I bought a metal knob.

A stereo stepped attenuator is typically the “professional” solution to my problem but I was already over budget for the build and I didn’t have room to fit a large component. On a hunch I went to Goodwill and happened to find an old record player with a volume potentiometer having the exact characteristics I needed. I switched it out and it turned out to be a perfect fit — I didn’t even need to drill out the hole. Unfortunately I didn’t take any pictures when making the change.

Notes

Overall this was a fairly straightforward and fun build. My search for the perfect volume control potentiometer and my improperly grounded input caused the biggest delays in the build. Otherwise, this amp is a perfect addition to my setup!

The post DIY Housing for 100W Audio Amplifier Module appeared first on Paul Bupe Jr, PhD.

Project Summary

This was a quick build of a 50W desktop audio amplifier based around the SainSmart 12V 50Wx2+100W TPA3116D2 board. The amplifier performed well into a 6 Ohm load and was able to hit “uncomfortable” levels (at a 4 foot listening distance) without distortion.

Parts List

• SainSmart 12V 50W x 2+100W TPA3116D2 2.1 Amplifier Board
• Self-Stick 1/2″ Noise-Dampening Bumpers
• Kmise Z2807H3 14 x 17 mm Mini Aluminum Knob
• Black and Red Plastic Shell Speaker Terminal Binding Posts
• BOX3-1455N-BK Black Aluminum Box (6.30 x 4.06 x 2.10 in)
• 2.1mm Metal Panel Mount DC Power Jack
• 3.5mm Stereo Panel Mount Input Jack

The Build

This project did not require any significant electrical design and was more an exercise of fitting components inside a relatively small enclosure. The initial plan was to have both RCA and 3.5mm inputs but the final product contained only the 3.5mm input due to the very limited space inside the enclosure.

SainSmart Amplifier Board

The build quality of the amplifier board was disappointing and was the cause of significant frustration during the build of this project. The biggest issue was the fact that the potentiometers were not evenly spaced and were also crooked.

Secondly, the power switch was slightly recessed which meant that the mounting holes for the potentiometers had to be drilled out to a larger diameter in order to allow for the switch to come out for enough to be reachable. The obvious solution would have been to desolder all the pots and resolder them properly. I did not do that.

Chassis

About the hardest part of this build was fitting the amplifier module in the chassis and cutting out the holes in the faceplate at the correct height. Due to the poor assembly of the board, no assumptions could be made about any features being equidistant so there was a lot of measuring and even more informed guessing.

The post Desktop Audio Amplifier Chassis appeared first on Paul Bupe Jr, PhD.