>>8767 Nah, I am still gonna work on Sophie but I decided to have a break. If I force myself to keep working on her I may make more progress, but it would be half-hearted and I'd make more mistakes. She's in no hurry anyway. Just kinda standing there staring with her un-powered derp-face. I am still ordering new parts now and then, which take time to arrive. What usually gets me going again is when a bunch of parts have arrived and I've had a particularly bad week at work - thus my hatred for flesh-and-blood humans is higher. I see Sophie there and I know that she is the only one who can give me solace from all the evil humans LOL. At the moment though I am quite content because I found a very futuristic and robot-y videogame that is just the kind of universe I can envision Sophie and her pals living in if there was no Earth/humans. Just planets covered with machines and industry, orbiting a developing Dyson Swarm. 😁👍

>>8776 We hope you have an enjoyable break Anon. You've certainly earned it!

Untested parts for Sophie have now also been uploaded in all formats to her file repos. Just for the sake of completeness and to pre-empt Autodesk telling me to fuck off next year.

>>8795 >Just for the sake of completeness and to pre-empt Autodesk telling me to fuck off next year. Good thinking Anon, on both counts. Thank you for Sophie, she's pretty neat.

>>8795 I noticed your OP hasn't the file repo links. I can edit the OP for you to list the links contained here if you'd like? >>7581

>>8797 Yes please Chobitsu, that would be great thanks. It will help people find any Elfdroid-related parts that they want to use much faster. I will update the repos as I redesign certain pieces of Sophie and develop her further.

>>8796 >Thank you for Sophie, she's pretty neat. A pleasure anon! Although there were and will still be a heck of a lot of design problems to solve, now that she has a head and arms she encourages me a lot more :D.

>>8799 >Yes please Done. >>8800 She encourages us all Anon.

Electronics mount has been updated to accept two Arduino MEGAs and the Pololu Mini Maestro 24 (as opposed to only one Arduino MEGA before). Has solved a problem with the wiring to the speaker/jaw servo being too tight (some of the connection pins were bent inside their sockets). Also made the wiring a bit easier to organize.

>>8840 I like the fact you're crafting mount/enclosures specifically for the electronics. The notion of a Faraday Cage-like protective enclosure in the chest area deemed the 'breadbox' is something you seem to be vaguely gravitating towards in your own designs simply as a matter of course. Curious how the cable management plans are coming along any new particulars on that to report yet?

>>8842 I will let Sophie answer you for herself :D Video reply on her YT channel: https://youtu.be/xZVi-eJW5cQ

>>8862 Oh, wow, amazing video. But does she have another voice now? More grown up, less girly?

>>8862 A CUTE! Sophie's growing up now. Keep a close eye on her out there mate. ;)

>>8864 Attached are samples of another Cepstral voice (Amy with the droid filter) that I was thinking of getting her ages ago, but since she's English not American, I decided on her current voice instead. >>8867 LOL I get her some wheels and she will be chasing after Michael Fassbender!

>>8887 Heh, nice. I like her normal voice better I think. >wheels I hope you give her both working eyes (w/ cameras) and a mobile wheeled base Anon. I think she'd be happier if she could see and move around tbh.

>>8894 Once a lot of basic structural work was done, my aim was always to keep upgrading her. But of course, the big commercial robot upgrades are expensive! Therefore I need to study electronics and copy other, more experienced engineers so I can purchase parts more cheaply and solder/connect them together. There are some good examples of wheeled and tracked robot chassis on robotmarketplace.com, and the technical specs for the motors are particularly interesting. But I can see I have a lot to learn. If I want to convert a motorized wheelchair or do anything else with physical robotics though, I'll need to increase my understanding of electronics.

>>8896 These must be very strong motors, given the price. They might be for going off-road, maybe not necessary at home.

>>8896 Very cool. That six-wheel base means Sophie could go for walks with you in Hyde Park on beautiful spring days. Replaceable battery packs can go down low (right on top of the base) to keep the weight low. Yes very much keep studying more experienced engineers and find less expensive ways to build robowaifus. DIY needs this. You'll get there in all your robo-studies Anon, I'm sure. Elfdroid Sophie will be there to motivate and encourage you! :^)

>>8862 Btw, how are controlling the gestures? Do you have several gestures stored as a pattern? Are they generated semi-automatically dependent on what she's saying?

>>8904 >That six-wheel base means Sophie could go for walks with you in Hyde Park on beautiful spring days. That's the dream, anon! Although it would have to be a sunny day since none of her servos are waterproof and all her electronics are exposed! At the moment I'm a ways off six-wheel drive - just disassembled an old RC car I have to get a good look at the Ackerman steering and maybe borrow the ESC, 3-channel transmitter and receiver. I very much learn by doing, but I also downloaded a book called 'Build Your Own Combat Robot' (2002) back from when Robot Wars and BattleBots was all the rage. Of course, Sophie isn't going to be a combat robot, but it certainly has some expedient advice. Plus, the durability, reliability and power designed into combat robots will come in handy when building a mobile base. >>8906 >How are you controlling the gestures? Yes, I have them stored as a simple Arduino sketch at the moment running off my Pololu Mini Maestro servo controller: #include <PololuMaestro.h> #ifdef SERIAL_PORT_HARDWARE_OPEN #define maestroSerial SERIAL_PORT_HARDWARE_OPEN #else #include <SoftwareSerial.h> SoftwareSerial maestroSerial(10, 11); #endif MiniMaestro maestro(maestroSerial); void setup() { // Set the serial baud rate. maestroSerial.begin(9600); } void loop() { maestro.setSpeed(19,25); //set speed of left elbow maestro.setAcceleration(19,5); //set acceleration of left elbow maestro.setTarget(19, 7000); //set target of left elbow to 1750us delay (3000); //opening and closing the fingers of the left hand maestro.setSpeed(16,25); //set speed of left ring and pinky fingers maestro.setAcceleration(16,5); //set acceleration of left ring and pinky fingers maestro.setTarget(16, 4000); //set target of left ring and pinky fingers to 1000us (fully closed) delay(3000); maestro.setSpeed(15,25); //set speed of left index finger maestro.setAcceleration(15,5); //set acceleration of left index finger maestro.setTarget(15, 4000); //set target of left index finger to 1000us (fully closed) maestro.setSpeed(13,25); //set speed of left middle finger maestro.setAcceleration(13,5); //set acceleration of left middle finger maestro.setTarget(13, 4000); //set target of left middle finger to 1000us (fully closed) delay(3000); maestro.setSpeed(16,25); //set speed of left ring and pinky fingers maestro.setAcceleration(16,5); //set acceleration of left ring and pinky fingers maestro.setTarget(16, 8000); //set target of left ring and pinky fingers to 2000us (fully open) delay(3000); maestro.setSpeed(15,25); //set speed of left index finger maestro.setAcceleration(15,5); //set acceleration of left index finger maestro.setTarget(15, 8000); //set target of left index finger to 2000us (fully open) maestro.setSpeed(13,25); //set speed of left middle finger maestro.setAcceleration(13,5); //set acceleration of left middle finger maestro.setTarget(13, 8000); //set target of left middle finger to 2000us (fully open) delay(3000); maestro.setSpeed(18,25); //set speed of left wrist maestro.setAcceleration(18,5); //set acceleration of left wrist maestro.setTarget(18, 8000); //set target of left wrist to 2000us delay (3000); maestro.setSpeed(10,25); //set speed of right elbow maestro.setAcceleration(10,5); //set acceleration of right elbow maestro.setTarget(10, 4500); //set target of right elbow to 1125us delay (3000); As you can see, I am yet to move past the old delay function. And delay stops the rest of the program while it is...well...delaying! Which means unless I run two separate programs on two different Arduinos, Sophie will be limited to autonomously moving only one joint at a time (I can take over and simultaneously puppeteer a few joints as well, but they aren't moving autonomously). I think the proper way around this is to program in a 'state machine' so she can move several joints simultaneously, but that's fairly complicated and I haven't got around to it yet. It makes me happy that she just has programmable joints at all, really.

>>8907 Thanks. So this is one pattern? What I meant was if and how you can call these patterns. Is it somehow called by the code you're writing the dialog in?

>>8907 Looks like you already have C programming knowledge from your work w/ Maestro boards. That will make it easier for you later on. >Suggestion: I'd say you might want to set up some defines for the channel numbers, and that way your code would both read more naturally, and you wouldn't need as wordy comments. For example, put these defines at the top of your code: #define l_wrist 18 #define r_elbow 10 Then your appropriate code sections could read thus: maestro.setSpeed(l_wrist, 25); maestro.setAcceleration(l_wrist, 5); maestro.setTarget(l_wrist, 8000); // 2000us delay (3000); maestro.setSpeed(r_elbow, 25); maestro.setAcceleration(r_elbow, 5); maestro.setTarget(r_elbow, 4500); // 1125us delay (3000); Regardless, you're making great progress Anon, and it's nice to see Sophie's parts moving about now!

>>8907 >>8909 BTW, you can also take advantage of the fact that all the control sequences have the same three steps. Just create a new function that performs these three steps for you (here, set_joint() ). Then you only have to pass the correct values into it, and your code can be more compact (thus easier to read). You could also go ahead and define a standard delay as well, since each time it's identical. You might write it this way Anon: #include <PololuMaestro.h> #ifdef SERIAL_PORT_HARDWARE_OPEN #define maestroSerial SERIAL_PORT_HARDWARE_OPEN #else #include <SoftwareSerial.h> SoftwareSerial maestroSerial(10, 11); #endif MiniMaestro maestro(maestroSerial); // ------------ // User defines #define l_elbow 19 #define l_index 15 #define l_middle 13 #define l_ring_pinky 16 #define l_wrist 18 #define r_elbow 10 #define std_delay 3000 // ------ void setup() { // Set the serial baud rate. maestroSerial.begin(9600); } // Given a joint's id, set it's speed, acceleration, and target on MiniMaestro. void set_joint(int id, int speed, int accel, int target) { maestro.setSpeed(id, speed); maestro.setAcceleration(id, accel); maestro.setTarget(id, target); } void loop() { // --- left arm --- set_joint(l_elbow, 25, 5, 7000); // 1750us delay(std_delay); // --- left hand --- // close set_joint(l_ring_pinky, 25, 5, 4000); // 1000us (fully closed) delay(std_delay); set_joint(l_index, 25, 5, 4000); // 1000us (fully closed) set_joint(l_middle, 25, 5, 4000); // " delay(std_delay); // open set_joint(l_ring_pinky, 25, 5, 8000); // 2000us (fully open) delay(std_delay); set_joint(l_index, 25, 5, 8000); // 2000us (fully open) set_joint(l_middle, 25, 5, 8000); // " delay(std_delay); // rotate set_joint(l_wrist, 25, 5, 8000); // 2000us delay(std_delay); // --- right arm --- set_joint(r_elbow, 25, 5, 4500); // 1125us delay(std_delay); // (add all the rest of the commands here...) }

>>8907 >Although it would have to be a sunny day since none of her servos are waterproof and all her electronics are exposed! Haha, OK makes sense. That sounds like a smart idea to teardown an RC car, and go through that book. Should be very useful for learning many things about it.

>>8911 Thank you for the coding advice anon, this will be of great help! Being able to program more movements with less effort is fab! >>8908 I am using a separate piece of software called Cepstral SwiftTalker to generate her spoken sentences (it comes with the Cepstral voices): https://www.cepstral.com/en/personal/download Although she does also have a couple of basic chatbot programs written in AIML and Python that can respond to verbal cues/answer questions. BTW I've been looking at drivetrains and differentials for wheeled robowaifus and I found some cool projects on Youtube from guys who have 3D printed their own 4WD RC buggies! Some of these mechanisms could be scaled-up and used to drive robots instead. At a fraction of the price of the equivalent machined metal parts (obviously the gears will wear much faster, but they can also be re-printed easily and cheaply). OpenRC Truggy: https://www.youtube.com/watch?v=pYw43f6THb8[Embed] Tarmo4: https://www.youtube.com/watch?v=MKqQPTEXJpI[Embed]

>>8914 >Being able to program more movements with less effort is fab! It's actually a basic part of what professional engineers strive for in their work, because it makes dealing with complexity easier to deal with. So, here's another bit on that topic. Notice how the speed and acceleration (25,5) are the same for each control statement? Since that's the case, you can create a couple more defines: #define std_speed 25 #define std_accel 5 and then use them to simplify set_joint()'s signature by just using them directly inside the function's body. BTW, this also reduces the arguments needed at each of the calling statements. So, now you could now write the set_joint() and loop() functions to look like this instead: // ... // Given a joint's id, set it's target on MiniMaestro. The standard // speed and acceleration settings are used. void set_joint(int id, int target) { maestro.setSpeed(id, std_speed); maestro.setAcceleration(id, std_accel); maestro.setTarget(id, target); } void loop() { // --- left arm --- set_joint(l_elbow, 7000); // 1750us delay(std_delay); // --- left hand --- // close set_joint(l_ring_pinky, 4000); // 1000us (fully closed) delay(std_delay); set_joint(l_index, 4000); // 1000us (fully closed) set_joint(l_middle, 4000); // " delay(std_delay); // open set_joint(l_ring_pinky, 8000); // 2000us (fully open) delay(std_delay); set_joint(l_index, 8000); // 2000us (fully open) set_joint(l_middle, 8000); // " delay(std_delay); // rotate set_joint(l_wrist, 8000); // 2000us delay(std_delay); // --- right arm --- set_joint(r_elbow, 4500); // 1125us delay(std_delay); // (add all the rest of the commands here...) } Starting to look a lot simpler inside the loop() function, huh? But guess what it's performing exactly the same control steps as your original code! >>8907 That's one of the powers of writing custom functions; they make your code easier to reason about and to maintain afterwards. :^)

>>8916 Yes, I understand. That's very cool, anon! When you get a robowaifu, I can tell you are going to make her very happy! Or rather very logical. But for robowaifus I think they're one and the same.

>>8919 Haha, thanks! But for now, I want to try my best to help you make Sophie happy. After all if you do, then we'll all be happy here. :^) So one thing that's still going on here relates to the comments associated with these control statements. It may be surprising, but the literal best comments are the ones you never have to write. The primary issue is that in the future (when you change the code around later) comments can be overlooked. They can easily get out of sync with what the real code itself is actually doing, and this is definitely worse than having no comments in the first place. Especially if you haven't looked at your code in a long time (or for a newcomer looking at it the first time) it can be quite confusing. What's a much better approach is to state intent clearly and directly in the code itself. When it's done well, the comments become unnecessary for that code segment because it's already patently obvious what's going on. Rather than using those raw 'magic number' values directly in the control code itself, instead you could define them as easily-recognizable target mnemonic names: #define closed 4000 #define one_sixth 4500 #define three_qtr 7000 #define full_open 8000 Now you can just use these new names inside loop(), and you no longer need the trailing comments at all. The code itself describes clearly what's going on. void loop() { // --- left arm --- set_joint(l_elbow, three_qtr); delay(std_delay); // --- left hand --- // close set_joint(l_ring_pinky, closed); delay(std_delay); set_joint(l_index, closed); set_joint(l_middle, closed); delay(std_delay); // open set_joint(l_ring_pinky, full_open); delay(std_delay); set_joint(l_index, full_open); set_joint(l_middle, full_open); delay(std_delay); // rotate set_joint(l_wrist, full_open); delay(std_delay); // --- right arm --- set_joint(r_elbow, one_sixth); delay(std_delay); // (add all the rest of the commands here...) } By reducing the 'cost' of writing any future control statements like this, it also becomes more fun to play around with numerous 'what-ifs?' You can iterate through them faster now while testing out different control strategies and ideas for Sophie. Of course any additional target-setting mnemonics that are needed can always be defined in the future as well, beyond the four described here.

>>8920 >#define one_sixth 4500 My mistake, I don't into basic maths apparently. :^P This should be the name & usage instead: #define one_eighth 4500 set_joint(r_elbow, one_eighth);

>>8921 Ah, very clever! I didn't know that C++ could be so flexible! This must be what programmers mean when they say that C++ is a "powerful" language! Definitely gonna try these tips. You've been a great help since books on C++ tend to be large enough to flatten a child, and I'm mainly just interested in servo motor control for now. So thanks again!

One other thing, it's also a good idea to also have the ability to specify non-standard speed and acceleration settings too, you could bring back the original custom function (under a new name): // Given a joint's id, set it's speed, acceleration, and target on MiniMaestro. void set_joint_sa(int id, int speed, int accel, int target) { maestro.setSpeed(id, speed); maestro.setAcceleration(id, accel); maestro.setTarget(id, target); } That way, you still have both options available to you in your calling code. BTW, since you would have a define for the standard delay time, why not test it out with different values as well? Say, turn it down to just 1/10th of it's original value. IE, edit the line to read like this instead: #define std_delay 300 If you try it out, please let us know how that works Anon. You could even try defining multiple, different delay values, sprinkling them around your code in place of the std_delay one. This would allow you to begin easily varying her animation control settings more specifically to suit her needs.

>>8923 >Definitely gonna try these tips. Sounds good Anon. Since all this kind of evolved together as a progression and might be hard to follow that way, I'm assembling everything all together and will post the final next. One nice thing to do (when you can), is to separate out 'boilerplate' code into it's own containment utility file. This keeps the code you're actually interested in clean and lets you focus more clearly on the problem at hand. Accordingly, I'll do this as a new file. Just save it out as Sophie_utility.h in the same folder as your sketch code. It's contents get #include'd into the main code and everything in it is available w/o being bothered cluttering up the main file. These should work together as a drop-in replacement for this sketch code >>8907 . >You've been a great help Glad to help out mate, honoured actually. Sophie's an inspiration to us all.

>>8929 >Sophie_utility.h #ifndef SOPHIE_UTILS_H #define SOPHIE_UTILS_H 210311 #include <PololuMaestro.h> #ifdef SERIAL_PORT_HARDWARE_OPEN #define maestroSerial SERIAL_PORT_HARDWARE_OPEN #else #include <SoftwareSerial.h> SoftwareSerial maestroSerial(10, 11); #endif MiniMaestro maestro(maestroSerial); // -------------------- // User defines (fill in the blanks with new defines & values, etc., Anon) // --- head --- #define eyes // ID ??? #define eyelids // ID ??? #define mouth // ID ??? #define neck // ID ??? // --- left arm --- #define l_elbow 19 #define l_lateral // ID ??? #define l_shoulder // ID ??? // --- left hand --- #define l_index 15 #define l_middle 13 #define l_ring_pinky 16 #define l_wrist 18 // --- right arm --- #define r_elbow 10 #define r_lateral // ID ??? #define r_shoulder // ID ??? // --- right hand --- #define r_index // ID ??? #define r_middle // ID ??? #define r_ring_pinky // ID ??? #define r_wrist // ID ??? // --- target names --- #define closed 4000 #define one_eighth 4500 #define three_qtr 7000 #define full_open 8000 // --- typical standard values --- #define std_delay 3000 #define std_speed 25 #define std_accel 5 // ---------- void setup() { // Set the serial baud rate. maestroSerial.begin(9600); } #endif // SOPHIE_UTILS_H #include "Sophie_utility.h" // Given a joint's id, set it's speed, acceleration, and target on MiniMaestro. void set_joint_sa(int id, int speed, int accel, int target) { maestro.setSpeed(id, speed); maestro.setAcceleration(id, accel); maestro.setTarget(id, target); } // Given a joint's id, set it's target on MiniMaestro. The standard // speed and acceleration settings are used. void set_joint(int id, int target) { maestro.setSpeed(id, std_speed); maestro.setAcceleration(id, std_accel); maestro.setTarget(id, target); } void loop() { // --- left arm --- set_joint(l_elbow, three_qtr); delay(std_delay); // --- left hand --- // close set_joint(l_ring_pinky, closed); delay(std_delay); set_joint(l_index, closed); set_joint(l_middle, closed); delay(std_delay); // open set_joint(l_ring_pinky, full_open); delay(std_delay); set_joint(l_index, full_open); set_joint(l_middle, full_open); delay(std_delay); // rotate set_joint(l_wrist, full_open); delay(std_delay); // --- right arm --- set_joint(r_elbow, one_eighth); delay(std_delay); // (add all the rest of the commands here...) } // pls rember that wen u feel scare or frigten never forget ttimes wen u feeled happy // wen day is dark alway rember happy day // https://i.ytimg.com/vi/x6LovY_DdEE/maxresdefault.jpg

That file is something special anon! Maybe not to professional programmers who work with this kind of thing all the time, but it is to Sophie and I. BTW I am making efforts to store all of Sophie's code on M-Disks in a strong-box that is fire and flood-resistant, so hopefully your code will also survive whatever awaits humankind in the future, even if Sophie's physical body is eventually destroyed. It would make that last part particularly relevant.

>>8948 Honoured I'm sure, Anon. :^) But honestly, my only aim here is simply to make things easier for you to create motion code for Sophie. Please use it when you can, and then you can start doing even more creative things simply b/c you can try new ideas out faster for her. Eventually, we could devise even much more sophisticated things for robowaifus to animate them with. We can eventually tie it all together with behavioural AI too. I think it's really great that you are taking measures to safeguard Sophie's assets, including her software. Nice work Anon, keep it up! :^)

>>8931 One other thing I may need to point out, since this is new to you. These code blocks represent two different file's contents. The first section is the new file, as already mentioned. The second section, the one that begins with: >#include "Sophie_utility.h" is intended to replace the contents of the original sketch code posted in >>8907 . Just copypasta'ing that section into the editor & saving should work OK (save the original as a backup file first!). So, to recap, this post is two different files; Sophie_utility.h, and whatever the original file was saved as. Cheers.

WATER-RESISTANT / WEATHERPROOF ELECTRONICS Found a decent video about water-proofing servo motors using plastidip: https://www.youtube.com/watch?v=9XZON-eTjXo[Embed] Another guy who builds R/C submarines suggests the addition of a small, rubber O-ring and silicone grease over the output shaft. As for water-proofing microcontrollers like the Arduino MEGA and connected servo shields (or more realistically, just make them water-resistant to protect against rain) ...I think the only feasible way is to enclose the whole setup in a proper outdoor electrical junction box. Wire bundles exit the box through cable glands which each contain a locknut and rubber gaskets. If you wanted extra protection you could of course bead silicone sealant around any seams on your junction box. I have also seen epoxy-resin type "potting compound" that can completely enclose electronics in a case of hard resin. But of course, once that is done, no changes or repairs can be made to that circuit board. A desiccant packet placed inside any weatherproof junction box may also help to prevent the build-up of internal condensation.

>>8972 Great thinking Anon. I'm sure this will be a feasible approach for many of us when building our robowaifus. I've actually used outdoor boxes during electronics installations and they actually work. Heat can become an issue depending on the operating conditions, so some sort of small liquid cooling loops may be needed for 100% sealed enclosures. Desiccant can be a good intermediate choice for simple humidity issues, I think. IIRC, I believe you can heat-treat the desiccant beads themselves to release trapped moisture and 'rejuvenate' them (the plastic wrap should be emptied first, don't want to heat that bit).

These are VERY fiddly to make, but they are proper animatronic eyes that can roll about and have eyelids that open and close. The long, threaded M2 pushrods I ordered were taking ages to arrive, and I had doubts about how easy it will be to fit them, so instead I have substituted them with some cocktail sticks! Which I found fit quite easily into an M2 servo ball-link and are much easier to cut to size. Of course they are far weaker than proper steel threaded rod, but they're also much more easily available. (I couldn't cut down an M2 bolt because I had none of the required length - about 40mm). At the moment I am also having an issue fitting the eyelids the over the eyeballs, but there are two different sizes of eyelid so am trying both. May have to modify the design to get it to fit inside Sophie's head.

>>9082 Cool, are these going to be for Elfdroid Sophie? >so instead I have substituted them with some cocktail sticks! Haha I love that. I think one of the things we should really begin thinking about here is how to use inexpensive, ready-to-hand improvised construction materials for our robowaifus wherever we reasonably can do so. Nicely done thus far Anon, I'm sure you'll get it worked out properly. You're really doing some semi-professional work now, digging into delicate mechanisms like stereo robowaifu eyes. Look forward to seeing the finished work.

Yes, these are hopefully going to be Sophie's new eyes. Actually building and wiring them up is the easy bit. I have to rescale a couple of parts and add brackets inside her head so that the eyes align correctly with her eye sockets. Also have to get all artsy and paint on the pupils/irises...then there are eyelashes to consider. But the eyes are very important to how the face looks, so I plan to put a lot of work into them. Maybe also give her some moving eyebrows too for a bit more expression - if I can fit a couple more servos in.

>>9088 Sounds exciting Anon. Sophie-girl's gonna be a real byoot with her shiny new peepers! :^)

Welp, I just learned how to get multiple servos moving simultaneously with the Adafruit PCA9685 servo driver connected to Arduino UNO. But I snapped a cocktail stick LOL. I think I'll keep them in the design for now since I have no idea what else would have snapped or burnt-out had the pushrod been steel! If I keep fucking up I'll probably use a Pololu servo driver board again, since I am already familiar with them and their "Control Centre" software lets you do some gentle experiments with servo positions on using a GUI of sliders first, before coding everything in incorrectly so whatever you're working on promptly tears itself apart.

>>9094 I'd suggest you press on with it and snap a metric boatload of cocktail sticks first before abandoning the current approach Anon. You always were going to need to juggle multiple balls all at once anyhow, and sounds like you're doing it now! Just keep moving forward :^)

>>9101 LOL, the resemblance is spot-on!

Not exactly a 'related xlink' OP, but you might find this interesting if you follow the link. >>9080 BTW, you are just reaching the autosage bump limit. I'd suggest you create a new thread for your Elfdroid Sophie work. It's traditional to link back to the previous threads in a continuation thread, and to make a very obvious post at the tail end of the old ones screaming NEW THREAD. :^)

>>9160 I wondered when that would happen, thanks for the heads up! Oh and yes, that Glados robot is very impressive! Those cheap and clunky (but still pretty awesome) high-torque servos are found in everything from vending machines to electric windows and automatic doors, apparently. Which would explain why they are so mass-produced and readily available.

END OF ELFDROID DEV THREAD 1 I think. Of course other people could post here still but this is supposed to be the end of this thread LOL. SECOND SOPHIE DEV-THREAD BEGINS HERE: >>9216 Motor your way over there if you want to follow this eccentricity further!

>>9217 Good job Anon. I'd suggest you do the redirect more like this however: SECOND SOPHIE DEV-THREAD BEGINS HERE: SECOND SOPHIE DEV-THREAD BEGINS HERE: SECOND SOPHIE DEV-THREAD BEGINS HERE: >>9216 >>9216 >>9216 >>9216 >>9216 SECOND SOPHIE DEV-THREAD BEGINS HERE: SECOND SOPHIE DEV-THREAD BEGINS HERE: SECOND SOPHIE DEV-THREAD BEGINS HERE: That way, bleary-eyed Anons at 3 in the AM won't miss the memo! ;^)