Dyne's LD-F1 (D-O concept) build

[Dyne]

T-Minus 6 weeks (minus two days)

So I've been busy churning away.  I've pretty far behind my projected schedule because I haven't even completed the design, which should've been done two weeks ago.  It is slowly coming together, just not fast enough for my liking.

Part of that is due to losing some time for health reasons (just the need to sleep and the occasional headache from staring at and thinking about CAD all the time), and part of it is just my sporadic energy.  But part of it is because I had to face up to the need for a major design change.

Specifically, I have switched from the printed flexible belt treads because my early tests indicated that I had some errors in my design and also that the chances of finding the correct combination of flexibility and other settings would require a lot more time than I have left, as well as convincing me that the chances of getting a good clean print of both treads were low.  I was having too many issues even on the small test prints.

Instead I began what I should have done from the start: design a proper tank-style track.  The art has always suggested that, but I've previously discussed why I didn't go that route.

Since the droid's parameters are relatively fixed, I wasn't about to try and kludge it around a commercial track drive frame kit (which are pretty expensive anyway).  But since I only vaguely knew how to go about designing a track system, I did a bit of research from makers I know of that have built such a thing.  James Bruton.  RCTestFlight.  Various Wall-E Builders, like Matt Hobbs and Mike Senna (see his video on designing the tracks, for example).  

Ivan Miranda had the biggest influence on my system, though.  I've been watching his channel for a few years, and he's done several tanks over that time.  The most similar to what I'm doing (in scale) was the RC Mini Tank that he did in 2020. LD-F1's tracks are heavily inspired by this (but a bit larger).



Those were some of the earlier iterations. I'm currently on V5, which I am calling final. It differs mostly in that it has longer pivot pegs, and is therefore narrower and has one fewer interlocking hinge section on each side, and a slight slope just inboard of each sprocket in case the track somehow tries to get off center (to nudge it back).




Having made the decision to switch, there were still issues to address such as trying to get the correct look. As I've mentioned before, the art indicates roughly 18-20 segments on each track.  Part of why I went with a belt was because doing that with a track is impractical on a droid of this scale (at least, it is if you don't want the droid to produce a lot of noise and vibration).

That's because dividing this length of track into only 18-20 segments would make the pitch between the ends of each segment greater than 2 inches.  Consider that the drive wheels are themselves only roughly 4 inches in diameter.  That means their circumference is 4 pi, or a bit over 12 inches.  In approximate terms, if you want to fit a regular polygon with ~2 inch sides into a circle with a ~12 inch circumference, your polygon will have -- at most -- six sides (12 / 2).  Can you imagine driving a droid on hexagonal wheels?  Budumpbadumpbadump.

So you need many more segments than this to make a smoother approximation of the drive wheel.  More than twice as many as the art, probably.  So I considered linking two or more rigid-but-jointed links with a single flexible traction pad to help make it appear closer to the artwork (they're the red ones in the picture earlier)



You could maybe do this, but you have to make one attachment for the pad as a pin in a slot parallel with the direction of travel, rather than a pin in a hole, because as the traction pads go around the bends in the track, they must traverse a greater distance than the links they are attached to (being further away from the center).  



The slots allow the pin in the slot to slip further away from the pin that's just in a hole (or rather, the pad itself moves further away relative to the pin that's in the slot).  Since the slot is parallel with the track, the pad can only move in this direction, and is constrained from getting further from the link it's attached to.  The result being that the pad is somewhat bent around the curve.

At least, that's the theory.  In practice, the pad has a tendency to bow upwards on the edges of the track, so you'd have to bias the curvature (my idea was to do it by making the infill consist entirely of a couple of solid lines that run across the pad's length from the inboard edge of the track to the outboard edge, so it's more rigid across the track's width, and more flexible from leading edge to trailing edge, but I never tested that).

Also, because the links need to be fairly narrow (mine are currently 21 mm) there's not much room for the slot without compromising the link's integrity.  Nor is there much room for pin (screw) installation or removal or for having more than two attachment points per link across the width of the track.

So I abandoned that idea for v1 of the droid, and just went with 1 traction pad per link.  I may even print most (if not all) of them in rigid plastic like the ones below.  They are mostly aesthetic parts now to make the tracks vaguely resemble the art.  



They don't really have to be flexible to follow the curvature anymore, and if I mix rigid and flexible pads, I can fine-tune the friction of the tracks by adding or removing flexible ones.



Also, the rigid parts print faster, which is kind of important since the links alone take roughly an hour each, and even the rigid traction pads take about 45 minutes each.  I need a total of 106 of each.  Luckily a friend offered to help by printing any parts that will fit on his Elegoo Neptune 2.

I may go into the process of designing the track system later, but if you are curious, I ended up with these parameters:

• Link Pitch: 21 mm
  
• Total number of links per track: 53
  
• Total Track Length: 1113 mm (53*21)
  
• Sprocket Teeth: 14
  
• Sprocket pitch diameter: 93.78 mm (this is the diameter of the circumcircle of the regular 14 sided polygon formed by the link pivots when fully engaged with the sprocket.  In other words, it's the diameter of the circle that all of the link pivot centers would pass through as they go around the sprocket.)
  

The most useful tidbit I came across was the formula for the sprocket pitch diameter.  Given a certain link pitch (P) and number of teeth (T), it's:
(P/2) * csc( pi / 2T )


Since fusion doesn't offer a cosecant function, you can't use that directly.  Luckily the cosecant is just the inverse of the sine function. The result is more like:
( Link_Pitch / 2 ) * ( 1 / sin(( PI / ( 2 * Sprocket_Teeth ) ) * 1 rad) )




Besides the track system, I've also done a lot of the modeling for the head (doors and attachment points and such) and I already printed the smaller section, wired up and tested most of the head LEDs and my ability to control servos via i2c, and tested the head animatronics.





Left side LED and head attachment screw holes (to be covered by orange stripe panel)




This is a test print of the left side of the face, upside down.




The full head mechanism and upper stalk.  I've since printed the four pieces of the lower stalk arms (green in the CAD) and tested them.




I need to finish a few things before I can print the other portion of the head, but I'm saving that until I can wrap up the body and tracks.  A tank droid you can drive around at a con is more entertaining than one you have to carry around.


I've been pondering how or if I'll work R/C in as a second control system. I've also finally gotten (edit: and successfully bound) a receiver for my FrSky Taranis Q X7 radio transmitter.  Awhile back I bought a Jumper receiver, which should've been compatible, but I had trouble making it work with FrSky's firmware shenanigans.  The new one is a FrSky RX8R. Still had to play with the firmware, but mostly to fix what I'd done trying to get the Jumper receiver to work.

I'm not entirely sure how I'd to go about integrating R/C, but I suppose I could just poll the receiver's servo outputs via the ESP32 and use those values whenever there's no PS3 controller connected. I could also go find an SBUS library and try to read the servos that way. I may want to use SBUS for telemetry feedback to the transmitter anyway.


I've waffled for a long time on what to use for the lift system.  A standard linear actuator is much too large to fit in the body, and the ones that are small enough are pretty costly, so I considered going with a DIY version, such as one based on this design by Michael Rechtin.





But then I would've had to spend time modifying it to fit the build, testing the mods, etc., and I would've had to gather all the components as multiple unit packs as well.  While individually the price of the DIY version is much cheaper, the combined price of buying the parts to build several of them is a significant fraction of the price of the off-the-shelf solutions.

I eventually decided to go with a Hitec Linear Servo from Servo City.  This single servo is the most expensive part by far on the entire droid, but I think it'll be worth it.  I got the HLS12-50100-6V ... 2 inch throw, 0.6 mm/sec speed (so roughly 4 seconds for full travel), 11 pounds thrust.  I don't know how much the head will end up weighing in total, but the neck stalks and big head servos shown in the photo above are most of the mass, and that stuff probably tops out around 1.5 to 2 kilograms (3.3 to 4.4 pounds).  

The servo is small enough to easily fit in the droid, is HOPEFULLY strong enough (probably is, as far as I can tell based on the rating while only guessing at the final total weight it has to lift), and is not ridiculously slow.  It also has decent holding force when unpowered, which is useful.  And in contrast with a linear actuator, a linear servo can be given a specific position to go to, rather than simply saying "move to the other end stop.  Now move back to this one."  That's useful for puppeteering, though I doubt I'll have time to code this in for the initial run.

My remaining concern with the lift system is making sure that the rear shell of the droid (which is one arm of the parallelogram that forms the lift system, as I've previously described) can carry the load.  I'm considering putting aluminum sheet under the printed exterior to bear most of the weight.  I'd hate to go through all this trouble and then break the back of the droid at the last minute.


I'm too tired to add pics or anything right now, so I'll come back and do that sooner or later.  (Edit: Done)