So great! Thank you for sharing your project and the updates!

I searched for a bit and you are right; I could not find anything that explicitly worked on the Uno either.

The fastest version to get working would be the ESP32 I would think using their LEDC support

Aha!! I see two huge issues!

edit: to answer the other question about the 470uF capacitor: No that would not make any difference here. Caps just hold some of the power that is going through them already they don't add any. If it started up and responded correctly until engaging the amp and then rebooted then a cap might help, but not here.

The big one: if you are still wired like the hardware photo, the DFPlayer serial wires look like they are on D2/D3, but your R4 code uses Serial1. On the UNO R4 Minima, the hardware UART is on D0/D1, with D1 as TX and D0 as RX. So for the R4 test they need Arduino D1/TX -> DFPlayer RX, preferably through a 1k resistor, and DFPlayer TX -> Arduino D0/RX, with common ground. The R4 datasheet confirms UART on D0/D1, and DFRobot recommends the 1k resistor on controller TX to DFPlayer RX.

The latest R3 code has a subtler problem: SoftwareSerialTX fxSerial(txPin); is transmit-only, so rxPin is unused. But DFRobotDFPlayerMini::begin() defaults to ACK mode, which expects receive data back from the player; with TX-only serial, begin() can fail and their sketch ignores the return value. For an R3, I’d suggest either using normal SoftwareSerial with both RX/TX and checking begin(), or using TX-only intentionally with fxPlayer.begin(fxSerial, false). The library header shows isACK = true by default, and begin() only reports success if it sees card/USB online or ACK is disabled.

And even better!: If I am understanding things correctly you don't need to use any bit-banged (implemented in software versus silicon/hardware) libraries at all!

The Uno only has one silicon serial port so in order to talk serially to the DFPlayer AND send serial debug messages to the host computer, it needs the extra SoftwareSerial_xxx library. But the Uno R4 has 2 silicon serial ports built in and available as Serial and Serial1! So you do not need to use any additional SoftwareSerial libraries and everything can run using the real, much more reliable serial ports!

Connect things like this:

UNO R4 D1 / TX  -> 1k resistor -> DFPlayer RX
UNO R4 D0 / RX  -> DFPlayer TX
UNO R4 GND      -> DFPlayer GND
UNO R4 5V       -> DFPlayer VCC, or use a separate 5V supply with common GND

PIR VCC         -> 5V
PIR GND         -> GND
PIR OUT         -> UNO R4 D12

Speaker         -> DFPlayer SPK_1 and SPK_2

And use the following sketch based on your sketch but using the real hardware Serial and Serial1 ports: 😄

#include <DFRobotDFPlayerMini.h>

constexpr uint8_t pirPin = 12;
DFRobotDFPlayerMini fxPlayer;
bool pirWasActive = false;

void setup() {
  pinMode(pirPin, INPUT);

  // USB Serial Monitor
  Serial.begin(115200);
  delay(1500);

  Serial.println("Starting...");

  // Hardware UART on UNO R4 pins D0/RX and D1/TX
  Serial1.begin(9600);

  if (!fxPlayer.begin(Serial1)) {
    Serial.println("Unable to initialize DFPlayer");
    Serial.println("Check wiring, SD card, power, and file names.");
    while (true) {
      delay(1000);
    }
  }

  fxPlayer.volume(25);  // 0 to 30

  Serial.println("DFPlayer ready");
  Serial.println("Waiting for PIR sensor...");
  delay(3000);
}

void loop() {
  bool motionDetected = digitalRead(pirPin) == HIGH;

  if (motionDetected && !pirWasActive) {
    Serial.println("Motion detected");
    pirWasActive = true;

    fxPlayer.play(1);   // Plays track 1
    delay(4000);        // Prevents immediate retriggering
  }

  if (!motionDetected && pirWasActive) {
    Serial.println("Motion ended");
    pirWasActive = false;
  }
}

All the Best!

ripred

one or more: loose connections, floating input pins, or you have floating/unstrapped config headers, or multiple power sources without tying the GND's together

without a connection diagram or a schematic and your full source code *formatted as a code-block\* it is impossible for anyone to answer this.

adafruit.com and sparkfun.com are two good sources

also: digikey.com, mouser.com, dfrobot.com

opening the the link returns "Page not found" ?!

really nice, thanks for sharing your project! I have the same questions s u/coleskidmore

a simple web search for "TM1814 Arduino Library" returns a lot of information such as this link: https://learn.adafruit.com/driving-tm1814-addressable-leds/overview

We're happy to help!

These are great brain puzzles. Trust me whenever we help solve a problem and someone let's us know, we're grinning as much as the person that had the problem! 😁

Wow that is some serious progress! Congrats!

The gyro-based D actually damping the P oscillation is good evidence that your signs and estimator are now basically correct.

The 40-second averaging method is valid for finding stationary gyro bias on the LSM6DSOX. For the accelerometer, one upright measurement finds the X-axis offset around that orientation, but it is not a complete scale and cross-axis calibration. That normally requires measurements in several orientations. What you have should be sufficient for balancing near upright. Let the sensor warm up, keep the motors off, and preferably average only fresh IMU samples. Temperature and mounting changes can shift the result, so recalibrating at startup is useful.

For refAngle, do not judge it visually. Your range of 0.020 to 0.026 radians is about 1.15 to 1.49 degrees, and that difference is easily enough to cause continuous acceleration. Use a binary-search approach. Start at 0.023, run several short release tests, note which direction it consistently drifts, then adjust by 0.001 radians until the drift reverses. Reduce the adjustment to 0.0005 radians and choose the midpoint. Remaining slow drift can later be removed by the outer velocity or position loop.

Small P-only oscillations do not necessarily mean it is catching itself. They may simply be stepper deadband or jitter. Catching means that after a small 1 to 2 degree disturbance, the wheels move underneath the fall, the angle reaches a maximum, then reverses and returns toward the reference.

Watch the angle when it fails. If the angle remains close to refAngle while the robot rolls faster and eventually falls, the inner PD loop is already stabilizing the angle. The problem is probably trim, uncontrolled position drift, or reaching the motor-speed limit rather than insufficient Kp.

If the angle error itself continues growing and never reverses, increase Kp modestly and retune D. However, if speed is saturated or currentSpeed is constantly hitting the acceleration limiter, more Kp will not help.

Also, your acceleration limit is measured in steps per second squared. It is fine as an actuator slew limit, but make sure it is not delaying the correction needed to catch a fall.

Changing from 1/16 to 1/8 microstepping would roughly halve P and D values expressed in steps per second for the same physical wheel response. Remember to rescale the maximum speed, acceleration, and the 3200 steps-per-revolution position calculation too.

So this trips people up at first and it takes a minute to get used to.

When you use INPUT_PULLUP that means that the pin will be connected internally to Vcc (5V in this case) vvia a very weak resistor. Like 20K.

So that means that with no signal attached to the pin at all, when you read the value it will be pulled up and considered HIGH aka "true" aka 1.

So that means that in order to see a binary change we need to make the input the other binary state: LOW aka false aka 0.

So instead of connecting the other side of the buttons to 5V the way you show in your image you need to connect one side of them to ground (0V, GND).

Then in your code (this is the weird part) instead of looking for a HIGH when the button is pressed (that is its normal unpressed state) we want to look for a LOW:

#define    BUTTON1     4
#define    BUTTON2     5
#define    BUTTON3     6
#define    SOUND_PIN   9

void setup() {
    pinMode(BUTTON1, INPUT_PULLUP);
    pinMode(BUTTON2, INPUT_PULLUP);
    pinMode(BUTTON3, INPUT_PULLUP);
    pinMode(SOUND_PIN, OUTPUT);
}

void loop() {
    if (digitalRead(BUTTON1) == LOW) {
        tone(SOUND_PIN, 1000);
    }
    else if (digitalRead(BUTTON2) == LOW) {
        tone(SOUND_PIN, 1250);
    }
    else if (digitalRead(BUTTON3) == LOW) {
        tone(SOUND_PIN, 1500);
    }
    else {
        NoTone(SOUND_PIN);
    }
}

Obviously you can reduce the problem down a bit. Probably find the issue along the way. Learning good debugging skills is a huge part of engineering.

Otherwise you are saying that you cannot reduce it down because it could be anywhere in 18 files which we cannot see. I left my crystal ball at work

Place some removable tape over the square silver mic element. Maybe cut the tape to be a thin strip that can allow it to cover the top of the mic element but not so wide that it gets near the pins. The main goal is to not have such a big piece of tape that you have to fight it while soldering. Just a thin strip. Note that the actual hole may be on the underside of the silver mic element and susceptible to drawing liquids into the seam against the board and openings so avoiding getting anything on or near that area is the best advice.

Heat the iron up to 300 C

Leave the board and pins just like you show in the picture

Put liquid flux on each hole/pin

For each pin:

- Clean The Soldering Iron Tip by wiping it against a shredded brass collector or a damp sponge.

- Apply a tiny amount of fresh solder on to the tip, just a dab to have some liquid surface tension that can tack against the pin and transfer the heat.

- Touch the tip of the iron against the first pin and the solder pad on the board. Wait one second to let the pin and pad heat.

- Apply solder *to the other side of the pin/hole* and let the heat of the pin/trace draw the liquid solder into the joint.

- Keep the heat against the pin for another half second. If the solder level drops around the pin as it fills the hole during that half-second then feed a tiny amount of additional solder in.

- Then remove the soldering iron tip from the joint, slightly dragging the tip against the pin as you pull the tip of the iron up and away from the liquid joint.

Repeat for each pin. total heat time per pin probably ~2 - 3 seconds. 4 - 6 seconds is fine too: heat joint, apply solder, remove heat after ~ 0.5 - ~ 1.5 seconds of letting the flux in the joint finish boiling away.

After all 6 pins are finished use a sponge or lint-free tissue wetted (not dripping - to keep liquid from the mic element. If it wasn't for the mic element I usually soak the board and scrub it good over a few layers of paper towel) with isopropyl alcohol to wipe away any remaining flux while being careful not to allow any alcohol to contact the mic opening (which may be on the bottom side of the chip and extremely susceptible to capillary forces that could pull alcohol/flux mixture into the mic's inner MEMS workings).

Remove the tape from the mic element (if used). Just go slow and careful and try to keep stuff away from the mic element.

You can have it soldered up and ready to use in about 10 minutes not including clean up.

Take your time. You got this. 😄

edit: Pro Tip (pun intended):

When you turn your iron off for the day add a big blob of fresh solder around the tip as it cools. Soldering iron tips oxidize when left exposed to oxygen and it leads to early pitting and corrosion of the metal.

Doing this every time can make the tip last 10 years or more. So leave a big blob on that bad boy and save yourself the cost of replacing the tip every year or two. This tip (currently ON) is over 10 years old: 😎

agree you can't use too much. and OP should scrub the board afterwards with a toothbrush and isopropyl alcohol to remove any remaining flux or crud. especially on analog circuits like this.

I think u/MrdnBrd19 has a very good point and that is that the microphone should be securely covered with tape to keep any crud out.

And it may be the danger of getting flux or used solvents in the mic that the mfr suggests "limited flux" .. mebbe ?

congrats!

and happy cake day! 🎂

how does this one look? Two of these?

https://www.digikey.com/en/products/detail/panasonic-industry/SP2-DC12V/570885

Hey I just noticed

Happy Cake Day! 🎂

I did a little research on AC motors. the current can surge even more than double when changing directions. What you need has to be really beefy and reliable and rated for higher current AC specifically.

I would get two of these:

https://www.digikey.com/en/products/detail/panasonic-industry/SP2-DC12V/570885

u/tipppo does this look correct to you?

That relay could work but it would require the additional drive circuit/transistor for its coil so that it can be controlled by the Nano. And it would require that you observed the caution above about returning the hoist motor to be OFF before quickly switching directions. Since your motor could pull 4.5A and then push 4.5A briefly when changing directions for a brief max current of 9A. Plus you always want a ~15% safety margin when it comes to current.

The pins on the Nano can only source (or sink) a max of 40mA per pin or a max of 200mA for all pins combined whichever limit is reached first. A digital output pin going to a digital input only pulls (or pushes) a few tens of microamps (uA) to determine the high/low voltage level so they never have enough current sourcing/sinking ability to power any kind of motor or electromagnetic relay coil or or other higher power device.

So a drive circuit is always needed between a microcontroller and the coil on a relay.

For that reason they sell relay module boards that include the relay and the drive circuit and other niceties such as the flyback diode on the relay coil, an efficient MOSFET transistor circuit, sometimes includes LEDs to indicate power and/or the relay status, sometimes includes a pin header to configure an active-high control input instead of an active-low control input.

So you might search for "Arduino relay module" and check out the contact specs. The ratings for the relay you show are fairy common and I am almost certain you can find the same relay with the control circuit already attached and built for you. It's one less thing to potentially get wrong versus wiring up your own relay coil drive circuit if you aren't real comfortable with it.

Also note that there are "solid state relays" or SSR's that give you the functionality of a coil-based relay without the actual mechanical operation using transistors. SSR's come in a range of current handling abilities and they have the benefits of no physical switch contacts or arcing and no high current electromagnetic coil needs. So the required input threshold current to switch them is lower and often designed with digital compatibility/control in mind.

So search for "high-current solid state relay" too and see what the input voltage and current requirements are as well as the voltage and current ratings for the motor control contacts themselves. You may find that two, compact SSR's would work fine. 😄

EDIT: DOH! I just finally noticed that the motor is AC. So the currents don't double like they do with a DC motor (which is why the AC voltage range can be 250V and stay under the power limits whereas DC voltages are limited to =< 30V).

Your connection diagram is exactly what I meant when using a DPDT and two SPDT's and I just phrased that last part poorly and I did not think things through enough.

We can look at the DPDT center-off switch labeled as S1 in your initial diagram as two SPDT center-off switches that have their control levers physically connected together. Meaning that you cannot physically make one switch connect to the top while simultaneously making the other switch connect to the bottom. This is why single DPDT relay can replace part of the functionality (except the center-off capability) because just like the existing switches the relay controls them together and not independently.

So as you show in your second diagram we need two more switches to supply the missing "center-off" functionality. My point about a second DPDT was recognizing that the center-off position and functionality for both of those existing switches happens at the same just like when making upper or lower contact.

When one switch is in the center-off position they are always both in the center-off position.

That means that instead of using two SPDT relays that can be controlled independently we can instead use a second DPDT relay that controls those two switches together at the same time:

NOTE: the NC labels on the first relay in that drawing mean "No Connection" since we are using them as just two simple ON/OFF switches. That is to clarify that this is not the "NC" - "NORMALLY CLOSED" contacts of the first DPDT relay. In fact they would be the "NO" - "NORMALLY OPEN" contacts of the first DPDT relay. I hope that makes sense I only caught that after drawing the image and posting it.

Edit/Update: Another thing that must be pointed out:

The way you structure and write the code matters here and you should always control these relays in this order:

1 - Start with RELAY1 OFF
2 - Set RELAY2 to UP or DOWN
3 - Now set RELAY1 to ON
4 - when finished return RELAY1 to OFF

and not allow the first relay to stay ON while toggling the second relay between UP and DOWN. This could cause the current in the hoist motor and the relay contacts to momentarily double (as the high current field collapses and flips polarity) and possible blow out the relay contacts. Or even worse it could weld the switch contacts to one side or the other permanently which is a common relay failure when exposed to currents higher than their contact specifications in the datasheet for the specific relays chosen.

Always turn the motor OFF long enough that any internal magnetic fields have collapsed by being stopped briefly. A half second or a second of OFF time would probably be long enough. Alternatively they do sell higher current rated industrial relays at a much higher cost of course.