Designing And Building The Micro Switch Mount

As I detailed before in a previous post, I had forgotten to print a mount for the homing micro switch on the motor mount. That's not the end of the world, as I can just make a little clip-on mount and place it perfectly relative to the motor mount, and use that to help drive the improved motor mount design.

Here is the basic operation:

Carriage in relation to homing switch location

When I run a home command, the carriage should move all the way to the right until the micro switch is triggered. This also seems like a great candidate to experiment with Arduino's hardware interrupt feature, but I'll get to that later. First step, is building the clip to position the micro switch correctly.

Modeling the Part

Because the motor mount has the same clip geometry I need, it makes sense to use that part as base for the new one. So I projected that profile into a new sketch and extruded it to the size of my clip. The rest of the geometry would be influenced by the position of the micro switch relative to the carriage at "home" position. For this, I needed to first model the switch:

Microswitch model

Then, I positioned the switch such that the edge of the carriage would hit it when there was just enough clearance around the rest of the parts:

Microswitch positioned relative to carriage

The final step would be to add geometry to the switch clip to meet the already positioned switch. So, I projected the switch face into the bottom of the clip, joined the two areas together with some arcs and extruded it beyond the switch face:

Microswitch mounting bracket

Printing and Assembly

The printing was a pretty straight forward process, once the part was done, all that was left was attaching the micro switch to the mount, soldering on some lead wires and affixing it to the frame.

Assembled microswitch and bracket

Installed microswitch bracket

Hardware Debouncing

I noticed while testing the micro switch some noise in the switch, using the multimeter as a continuity check, I heard more than one "beep". As such, this switch would benefit from a debouncing circuit so that the signal sent to the Arduino is definitely either high or low.

To do this, I followed this great tutorial which will involve the following parts:

  • 1x Schmitt Inverter CD40106BE (datasheet)
  • 1x 10k resistor
  • 1x 10uF capacitor

Starting with the Control Button

Because I already have a working button with code backing it in the form of the position cycle button, I'll experiment with the hardware debouncing logic here. If it works, I'll carry it over to the microswitch. Let's start with the schematic:

Debouncing schematic

This diagram is rather simplified, because it only shows one of the inverters and the power and ground leads for the IC separately. Below is a picture of the parts on the breadboard, but it is not that helpful and kind of confusing at the moment.

Schmitt inverter installed on breadboard

The initial test turned out to be a success, so I thought it would be worth adding the micro switch in place of the button to test that, which also worked just fine. In returning the circuit to the original state, I added debouncing for both the control switch and the home switch.

Programming the Home Function

There are two ways to think about this operation:

  • Home subroutine.
  • Home interrupt with subroutine.

The first, a more simple subroutine, would have this basic logic:

  1. Start moving toward home, polling the switch.
  2. If the switch is high, set the position to zero and wait for input.
  3. If the position is low, continue to move toward home.

I'm not wild about this, because it requires checking a switch for state on each cycle and more often than not, the switch would be low. "Homing" should only really happen when I turn the machine on and when there is a screw up. I'd prefer the home process to occur whenever the button is pressed, this way, if some wise acre moves the carriage in between waterings, the movement will be stopped by the home interrupt.

Iterating on the Logic

I went through many iterations of the home function logic to understand how interrupts worked and the Arduino loop system. The result was a near complete refactoring of the existing code. Plus, I cleaned up the variable names and comments a bit too.

The result was a multi-function button:

  • Press for more than a certain threshold, I'll trigger a home routine.
  • A normal press just increments the number and consequently, sets the moves the carriage to that position.

The basic movement logic is captured in this statement:

  //Movement logic sends carriage to a location based on distance in mm and direction (-1 is right, 1 is left)
  if (absoluteDistance > 0) {
    digitalWrite(stepperEnable, HIGH);
    stepperMotor.step(direction); //Move a single step either right or left based on sign
    if (currentPosition >= maxDistance + spoutOffset) {
      absoluteDistance = 0;
    } else {
      currentPosition += (direction * stepLength);
      absoluteDistance -= stepLength;
      if (absoluteDistance <= 0) {
        Serial.print("Current position: ");
  digitalWrite(stepperEnable, LOW);

So often, other parts of the program change and reset the absoluteDistance and direction. When I hold down the control switch, I tell the program to change the "amount to go" to a large value, and the direction to the right. The carriage then moves all the way to the right where it hits the home switch.

The home switch then updates the settings again so that on the next loop, it starts to move to the correct position relative to home.

void resetHomePosition(){
  direction = 1;
  currentPosition = - homeOffset;
  absoluteDistance = homeOffset;
  displayNumber = 0;
  oldDisplayNumber = 0;

Similarly, each time I increment the "position" display, that value is used to fetch the distance and direction needed to go to that location from the currentPosition. I also change how the distances were fetched from an absolute list to dimensions driven by some settings:

float getPlantLocation(int plantNumber){
  if (plantNumber == 0){
    return 0;
  float plantWidth = maxDistance / numberOfPlants;
  return ((plantNumber - 1) * plantWidth ) + (.5 * plantWidth);

The net result, is that you would choose to have between 1 and 8 plants, and they would be evenly distributed under the frame. For the full source code, check out the github repository.

Next up...

Next, I'll be tackling the water and lighting control circuit which will let me test this bad boy on some plants. I was recently able to procure some more parts that should aid in improved LED drivers.

If you enjoyed reading this or learned something, please consider sharing via , , or . Thanks!

If you enjoyed this article, you might like others related to the Robotics interest. This article is part of the Robogarden project.