Automatic Hot Chocolate Machine

I really think you could have included a grinder and maybe a little dude at a piano! 🙂

Nice work man.

Thanks 🙂 I might add a smoothie maker and SATNAV, and an automatic joke dispenser for when I'm feeling low on witticisms. But unfortunately that would mean buying more parts, and I don't want to deal with shipping costs right now.

(Titters quietly to self in recognition of a familiar issue us creators face)

First part done! This is the mechanism that will stir the powder into the heated milk/water. I've built it out of LEGOs, because that was easiest. The motor and controller you see there are only temporary to make sure the mechanism works. Essentially one motor will turn, lowering the whisk into the mug. Another motor (the yellow on on the end) will spin the whisk to mix, and when it's done, the first motor will raise the arm again.

A quick overview of the machine so far. The pump is inside the electric kettle (it's a mini portable one), and the mug is on the other side of the board. I've just begun designing the circuits, and hoping to high heaven I don't have to order any transistors or other such parts. The little upside down black container halfway up is the mix dispenser, and it has a servo motor controlling a piece of material covering a hole, which will let the mix out. This is really a prototype of the prototype--I needed to throw everything together in a rough form so I could make sure the code works, hence the cardboard. I can build machines perfectly well, but I'm much less confident in my skills as a programmer, and so I'll need to iron out that part of the build as quickly as possible.

@imp-inventor you should use ESP 32, to make it wifi controlable, you can later implement it in home assistant if you are using one.

@muzammil17 Actually the one I'm using does work over WiFi. I'm using the Arduino Uno R4, which has the ESP32 module built in.

OOOh nice work man!

I've come up against a rather irritating problem. Whenever the program runs, the servo motors start twitching back and forth, even though they're receiving no signal from the Arduino (well, they did receive a reset signal but after that, nothing, and they still twitch). As the hopper gate is controlled by a servo, this means it dispenses a tiny amount of powder with each twitch. I Googled it, and apparently this can be caused by an unstable power source--like USB--but it's powered by a 12v 1.5a adapter plugged into the wall. It can also apparently be caused by not utilizing common ground in your circuit, but I've done that as well. Does anyone know a fix to stop them twitching? It's not a fatal flaw, but it is a little messy, and the constant noise from the servos is driving me up the wall and across the ceiling.

Oh man, I feel that one - sounds like the persistent whine I could never quite cure on the Michelle. It got so bad the cost of the project ballooned but in the event what we got is (while still technically a beta) a very good board indeed.

But yeah, flickering servos. What they're talking about there is called "ground bounce" where a high current switch (usually a FET output going High/Low or Low/High.

[B****er me, that's three times today already... :/]

Sorry man, I keep getting notifications and it really jiggers my thought... [and again...]

I haven't done any serious servo encoding [lemme check] and there we are:

Not ground bounce, not dirty power - the spoiler above should point you in the right direction (this was my guess but it was better to check). 

The problem is the Arduino's timer primitives are (*snicker*) less than ideal. The microsecond tick which is where it's all hidden as I recall is little more than a suggestion! Now if your code (the library in this case) relies on that timing to the microsecond, and the counter comes back to late (as it often does!) then the whole routine goes to pot, the servo gets bogus angular data and it chatters.

Why chatter? The arduino is running loops within loops and at the deepest level, although this is all deterministic, so much is happening that we see (or experience) some sort of randomness. I forget where but there someone did a very accurate low-level version of microsecond although it might have been for his own code. If you can find it, I've no doubt one of the "coding AIs" could show you how to drop it in so the Servo library uses it and that should make the problem vanish at the next boot.

{Probably, YMMV, This has been a Public Information Broadcast, usual disclaimers apply, ya-de-ya}

Don't ya just love open source? it's free but sometimes it's only worth what you paid for it.

@marcdraco The odd thing is it didn't always happen. It started twitching about halfway through the circuit design, which is part of why I'm so confused. Both servos were perfectly fine before--one is being powered straight from the Arduino 5v power source, and the other is powered from a 6v battery pack, made of 4 AAs. And then suddenly they started acting like they'd just taken a bath in espresso. Once they're "attached" in the code (I guess once they start receiving signals), they simply won't stop twitching. Again, it's not fatal, just very irritating. And it's not really something I have time to fix--I only have 11 days left to finish this machine 😬

I literally could be nothing more than the temperature of the internal timing circuit when they are running (in idle). Cheap servos (and mate, I LOVE cheap) are cheap for a reason. If you have the funds/time it might be worth swapping one for something from a better supplier. Microservos seem to be particularly troublesome in this regard, probably a case of hard to make well, I guess. Not like solid state chips. Anything with moving parts is a nightmare.

@marcdraco Temperature, huh? Is there perhaps an optimal temperature I should be aiming for?

Unfortunately, preferring mechanical engineering to electrical engineering, I deal in moving parts.

I'm unsure as to the quality of one of the servos, as it was an extra piece from a friend who didn't need it, but it looks like an RC car servo. 25KG, 270 degrees rotation. The other is definitely one of those cheap blue ones, so I wouldn't be surprised if at least for that one the reason is lack of quality.

Neither of those are really intended for constant use - i.e. being powered and receiving a signal all of the time.

They SHOULD be fine but there's "should" and "is" -- well that's a problem all of us face. If you're of a mechanical bent, (sorry, no "finite thingy stress analysis" pun intended).

Likely the donated one is better by a good margin but that will mainly be in the gearing and the motor which is (being for an RC car) going to an an impressive heave as it's going to be getting yanked by forces transmitted through the couplings. 

Quite seriously I'd hit this issue head on myself - not with servos - but with over-torquing something, repeatedly, even when it creaked and groaned (and obviously against the designer's advice) and it's a good design too, to be fair, if evolved rather than thought through from scratch. Anyway, so after repeatedly hoiking and generally abusing it for weeks while I moved house (OK, hovel) I got tennis elbow. 🤣 🤣 🤣 🤣 

No really I did (the gag there as you will appreciate from a mechanical standpoint) is that the stress of using (my non-dominant, therefore weaker) arm to do stuff like torquing screws at weird angles and extensions for hours at a time, day in day out... Yup. 

So to your servos... and enough of my old age creeping up like the tide coming in at sunset...

They both, very possibly, use the same controller chip deep in there. Or it will be from a similar family (no point reinventing the wheel) a bit like Op Amps when a design solidifies, they stick to it. Since the control electronics are fairly standardised, they can push the money into protecting high-stress, wear-adjacent parts OR they can save a ton and make one of those ones that Amazon gives us if we eat all of our vegetables.

This is (really) more a job for a stepper than a servo because the signal is not in a feedback loop. It moves, it stops and it stays there until you tell it to move again.

Steppers are found mostly on things where there's more than 270 degrees of freedom (3D printers being the canon these days) but similar motors are used in better robots for accurate directional control.

Temperature wise, I'd be more tempted to blame the Arduino (esp. a clone) as functionally the timing ultimately depends on a crystal locked operator but not all crystals, or xtal oscillator designs are equal. Now a few % drift might not sound much, but it can prove cumulative and a temperature change of just a few degrees can have a serious impact. I expect the worst of it though is entirely down to that uSec tick which is (sadly) about as accurate as the information coming out of Twitter/X.

We can look at the electronics - but working with what you have, I'd still guess it's that wretched uSec timer function which is known to be "buggy" largely as a result of how deep it is embedded. A tiny error there, since the data stream is constant is going to send those fellas chattering like a couple of old dudes stood at the bus stop in the snow.

The diagnostics aren't as clean as pulling a plug.

But each part has to be tested in isolation (at least where practical).

Unless it's a major teardown, I would suggest you try the Arduino (Nano/Nano clone?) with a normal 5V USB dock PSU. Those are fine. Sharing the "ground" not idea for very low-level stuff (while necessary) but for high-current, all that matters is the servo has its own separate power. That way you can isolate the issue to a servo error (if the blue is worse). Or an Arduino cockup in the low-level stuff the Servo library is built on - which is honestly far more likely.

@imp-inventor use a capacitor inline with the power going to the servo, it should fix the twitching. even i had same problem.

Oh nice one man!

Sounds like the messy power is worse than I'd expected. (Feels good doesn't it! Well done.)

@muzammil17 That's a pretty good idea; any specific type of capacitor?