As a mad engineer, it's a very special moment in my life when I get to make two of something. For starters, the second one is always better. But more importantly, making two means I didn't make a device, I made a design.
A single device helps you. A design helps the world. And to make a robotic controller with a set of robots, that's just fucking sweet.
As one might expect based on the level of testing we'd done, the active target worked but perfectly. This is a list of the errors we saw, roughly in order of importance:
New printed boards to run the targets have arrived. For once in my life, I may not have made a significant mistake on these boards. I found exactly two sets of holes that were off and not by enough to matter.
I've done verification of the connections with the motor and the encoder on the target stand. I've also double checked the connections on the DC-motor-controller. Therefore, it's time to solder. And talk about what exactly I have here...
For starters, the goal of this device is to run 4 target stands from a single controller. It can then run an algorithm of targets to shoot on those 4 stands.
First things first: The connection with each target is an ethernet port. This was a tough call. I worked hard to reduce the number of connections needed but just couldn't. I need 2 to run the motor and 3 for the encoder, which tells me it's position. I could buy a special connector and use wire that's shielded (since some of the info is low-power analog). Or I could just use one of the most common connector ever: Ethernet. The wires have 8 connectors, can handle plenty of current for what I need (less than 200mA for the motors), and I'm pretty sure they're shielded. The only problem is that I'll risk some dumb shit plugging the target controller into an actual computer and frying it. Just this once, I'm going to trust humanity remember simple instructions like that.
Next up, the microcontroller itself: The arduino Uno is a very convenient device. I've used PIC chips which are cheaper but they often have special interfaces that most people won't have and therefore couldn't easily configure. Also, if you've ever used other less-user-friendly microcontrollers you'll find there's an endless mess of configuration you have to sort though. Sometimes it's easy and it just works. Sometimes you can't get entire sets of pins to work because they're configured for some other function and it's impossible to figure out how to turn that off. So I'm using a more friendly and user-modifiable microcontroller.
Now, how do we attach the arduino? Set a bunch of pins out of our board that are in exactly the same position as the plugs of the arduino. Then we can just plug our board into the arduino board.
Otherwise, I've got my simple DC motor controller in there and a rotary switch that'll be use to select and tell the microcontroller which algorithm to use.
This weekend, I expect to have a chance to actually run the targets and see what yet undiscovered errors I've made that prevent this from working. :)
If I need to prototype a circuit, I'll do it with wire wrap. I've found this is much more reliable than perf boards (where you just press the parts in at the right places). For some reason those always break on me and then I get inconsistent results from the circuits I build there. I think a major problem on my end is using components that are too big and then I have to really jam them in.
When the time comes that I need to make many of the same circuit (which is idea, design once and use again and again) then I need to get PCBs printed. I used to use pcbsingles.com in which you could draw the picture in paint or draw and they'd automatically print and drill it. Recently I placed an order and found they were out of business. When the owner told me this, I asked for a recommendation and he noted this place: ExpressPCB
ExpressPCB has their own board design software, but it's free and actually quite good. Much easier than doing this work in draw. And they're clearly encouraging you to do the circuit layout and then the routing. I haven't tried that yet since I knew many of my components wouldn't be in their library and I needed to have certain ports facing the outside, etc.
I just placed my first order and we'll see how it turns out. Hopefully I didn't fuck it up.
I've made a new target stand. And a lot of errors... that I've since corrected.
The main error I've made is that I tried to violate one of the core rules of engineering: Don't build it if you can buy it. I tried to build a DC motor controller.
I was building a DC motor controller because this new target stand is powered by a DC motor. It has to turn both clockwise and counter clockwise. I already needed such a motor controller for my big moving table, so I figured I'd just finish making it.
So I built an H-Bridge. Initially it was able to show me +/- 5V when I asked it to. Perfect, works the first time! And it burnt out once I put it on a 12V power supply. Some internet searching and logic informed me that it turns out is suffered from something called 'shoot through'. This can be solved with the use of special H-bridge motor controllers.
I build a new motor controller on the perf board of the old one, and it didn't work at all. I build it on a proto-board and it didn't work. I tried two different kinds of H-bridge motor contollers and they didn't work. Maybe the old perf-board mosfets were more fried than I thought. Maybe the proto-board was broken from pushing parts that were too big into it. I don't have another day to waste on that. Fuck it.
Since this is a low power motor controller, I just bought one. I don't need a high power controller like the table will. They're like $6. What was I thinking?
Slap that shit together and now the table works, again powered by an arduino. At the end of the video you can see it fall apart, turns out I only put a single spot weld on the axle holder. The next day I painted that steel on thick and it works like a charm again.
This first target stand is clearly very basic. It's actually powered by a car door lock, which will pull the stand into position and then it's returned by a spring.
I went with a car door lock as the actuator because it is strong (10lb pull) and car door locks are common enough to be very cheap (~$15).
The problem is that in order to show the target, the actuator has to be pulling constantly. After about 1/2hr of turning the actuator on and off I noticed it was getting sluggish. On closer inspection that actuator is very hot. On measurement, the actuator was pulling 2 amps while it was on. This is not acceptable, far too much heat. After significant work, the machine is going to overheat. I need a different system.
Question: What is an active target?
Answer: An active target moves on it's own. Re-active targets are already quite common in the world. The simplest version being a single plate of steel that, of course, makes a *ping* noise and moves when you shoot them. By contrast the active target will move into and out of sight to make shooting that target harder
Question: Why would you build one?
Answer: I'm guessing that if the targets at the range also move it will make me a more reactive shooter and be a better game to play. The problem is that the only active target I've seen for sale is LaRue's ~$1500 popup targets.
Question: How can you build it better?
Answer: The 'professional' versions here use a big steel plate that you shoot at. This means you can't use large weapons like a 50BMG. This also means you need a big engine to move it up and down quickly. And then you need a big steel plate to protect all the machinery that moves it up and down. And a big battery to power that motor. Etc. Etc.
Instead, I'm going to have a simple paper or wood target that isn't going to try and resist bullets. Similarly, instead of having the target lying down and pop-up, it'll be cheaper from a power perspective to have the target turn on an axis.
Have you ever wondered whether a truss with a single cross bar is better than a truss with many of them? How many cross bars exactly do we need?
Sure, we see a lot of things with truss bars at 45-deg angles so we can assume smart engineers determined this was best. But was it best for reducing deflection or was it best for strength to weight? If they were doing it for total strength to weight but not for deflection to weight, I might want to do it differently.
Let's start with strength calculations of the single cross-brace truss. If we assume the weight of the steel in each beam is 1 lb/ft and the truss is 3' then we end up with 11.16lbs for the truss.
What's the strength of that truss? Let's assume the steel will not buckle or compress, and it has a pull strength of 10,000 lb/beam. So if a beam was hung vertically and we put 9,999lbs on it, it'd be fine. If we put 10,001lbs on it, it'd break. If we put a weight on the end of this truss we see that center beam will break at a weight of 3,160 pounds on the end.
What about if we had that same 3' truss with 3 spans? Now the weight is 14.24, a lot heavier. What's the strength? This is harder to calculate. The way to do it is one truss section at a time. Let's start with the last truss section, it will take 7,070 pounds to break that center beam. What about the one before it? Well the last truss section only adds a few pounds of weight so this one will also break at around 7,070 lbs. Same with the section before this. So this truss is actually the strength of any one section, assuming the weight of the truss is negligible.
If we divide the weight a truss can hold by it's own weight, the multi section truss gets a ratio of 496 while the single section truss gets only 283. So the multi section truss is 75% stronger for it's weight.
What about deflection? Does the single truss deflect less? Could that be an advantage?
I made a model of this on my nifty new structure simulating I've been using for the mech. I allowed for 20% stretch in the sections that would be experiencing it; both the top piece and the cross bar of each section. I modeled trusses with 1 section, 3 sections, and 6 sections. The 3-section truss puts each cross bar at exactly 45 degree angles.
It's easy to see from the model the 3 section truss is deflecting less. It deflects 1.8' while the 1 section truss deflects 2.2', 22% more. Then again, the 3 section truss weighs 28% more. Here though I don't think we can just take the weight ratio. The weight ratio was appropriate before because we could just thicken the truss bars to increase weight and strength linearly. The bar thickness will not have a linear relationship with deflection. For starters we haven't defined what the stretch algorithm is, we just set it to 20% arbitrarily.
How are we going to get a handle on this? For starters we know that stretch is usually linear with strain in steel. And that mild steel will top out around 0.2% stretch before it breaks. So if we made our bars in the 1 section truss 28% thicker, we'd reduce the stretch about 28%; to 0.1448% stretch. Now our two sections are of equal weight but the 1 section truss deflects 20% less.
Unfortunately, to get here I had to make an assumption about the stretch on the top of the truss, that we're going to have all truss sections of equal thickness, and that buckling never happens. But in the end it's clear the many-section truss is shit, the truss with 45-deg cross bracing is strongest by a good margin, and the 1 cross brace truss probably has the least deflection but only by about 20% of minimum possible deflection.
The real goal here is to get the models to fully represent the mech. Now the act of modeling everything in detail will force me to consider the entire design before I start building and serve to make the simulations work just like the final product will.
I had some problems with the mech's feet and their colossal weight. I've made some reductions in the main spans to get the margin of error to about 8X it's standing strength. I also made the assumption I'd be using an alloy steel that's about 2x as strong (125k psi instead of 60k psi).
This has brought the mech feet down to 298lbs each, which is exactly under my target weight.
I'll need to do more calculations about the torsional forces on the foot that I've not yet figured out how to do. I also bought a book on material science to better understand what I'm doing now that I'm relying on more complex material properties for strength.
Also, while I was mulling over my changes to the mech I spent some time working on the table. I finished the H-bridge controlled that will drive the motors. It needed some debugging but then when it 'worked' it blew up, fracturing one of the transistors with the heat. It's clear there was a moment when both the high and low on one side were both conducting, allowing a high amperage of 120V through it.
Investigating some non-home-made H-bridge drivers I see that they often tout their abilities to prevent this. I bought some. I hope that their bragging about this feature does not imply that some of them still fail at it...
In other news, I left the soldering iron on when I got distracted by an attractive girl in my bed and need to buy a new tip for it.
I just added the density settings to the mech feed that I designed and it looks like they're already super heavy. Just one foot is 852lbs.
I'm using 3"x3"x0.25" steel for the main spans, 2"x2"x0.25" for the long (1") cross bracing, and 1"x1"0.25" for the short cross bracing.
The goal at this point is making the mech match what I'll actually build. That way the simulations will be accurate enough to determine the exact walking sequence. Similarly, I'll be able to get the collision detection and weight measurements correct.
Got the basic supports done for the mech foot. I'm using a helix or spring-like pattern to prevent the truss that connects to the leg from bending in the face of the torque from the feet. I'm not yet sure how to measure the stresses on it.
The next stage of mech design is actually designing the steel structure of it's feet and legs. This will also be my first trip into the land of structural engineering.
So how beefy do those feed need to be? Let's assume for now that we've got the center of mass at the center of the mech, 4' from the leg. And let's assume the feet extend 6' into the center. Given a 2000 lb mech, we now have 8000 ftlbs of torque and 1333 lbs of force felt on those foot spikes that extend toward the center and keep the mech from falling to one side of the other when it lifts a foot. Let's call that part the 'toe'.
If we assume there are two main bars in that support the toe and the foot is 1' high, the angle made by the bars is 9.5degrees. That works out to some 8110lbs of compression force felt by that top bar. The bottom bar will feel a tension force of about the same. Now the question is: what kind of bar do we need to handle that?
According to me metal supplier, onlinemetals.com, is takes ~60,200 psi to distort 316 grade stainless steel. (I'll probably not be able to make this thing entirely in stainless, but I like to dream) If I use a 1" diameter rod of stainless steel, it can hold 47,280 lbs. So that's more than enough.
That doesn't like it would be enough to hold 1 ton of mech at a bad angle does it? I suspect that my mind has a biased view of the strength of steel because I so often interact with tube steel rather than solid rods of it. Hold a solid 1" diameter rod and it's almost surprising that anything could break it.
So Now what about the ankle joint? There's a single rod that has to hold the foot to the leg. That rod must take the entire torque of holding the mech up. What kind of rod do I need there to keep it from sheering off with the force?
If we assume the leg supports are 6" apart (and remember, we now have 4 bones for each leg section), and apply the 8000 ftlbs of torque to it we come up with 16,000 lbs of sheering force on the bolt.
According to wikipedia, steel's sheer force is about 0.75 of the yield force. That comes out to 45,150 psi. If we use a 2" bolt here, it comes out to 3.1415 cubic inches of area and 141,842 lbs of sheer strength.
By the numbers we could use a 1" bolt with a sheer strength of 35,460 lbs but that's dangerously close to our 16,000 lbs limit. If we saw shock from ground impact or slipping, has temperature effects, or generally just mis-calculated that bolt could sheer and the mech would fall over. In reality, I'm probably going to use a 2" bolt for the ankle and maybe 3"x0.25" angle iron for the feet.
Of course, as always, I have no idea what I'm doing here. Thank science for textbooks and the internet...
I hear a lot about just how strong a 50BMG is. I wanted to know just how true all that was. So we pitted a 50 BMG, a 7.65x53 mauser, and a 5.56x45 AR-15 against a steel plate.
At ~700 grain the 50GMB is heavier than the 63 grain 5.56 and 174 grain 7.65. The 50BMG is firing out of a 29" barrel for a solid 2,500 ft/s vs the 2,460 ft/s of the mauser. Here the 5.56 scores better even out of it's 16" barrel at ~2,900 ft/s. That puts the 50BMG at ~10x the power of the AR and about 6x the power of the mauser.
For this test, we only have solid lead shot for the mauser but we've got basic (non-explosive) armor-piercing ammo for the 5.56 and 50BMG.
... and we have a 1" (~25mm) thick mild steel plate. Getting a hardened steel plate at this size would cost ~$300 and so we'll test hardened vs. mild steel with some smaller rounds and cheaper plates. I actually suspect hardening protects only slightly better or not at all better but does have the property of being all-or-nothing. That is a hardened target will be either totally broken through or shrug off the round entirely, while a mild target will get ever larger craters until it's broken through. But I digress, and we will have to test that.
At 100 yards, the 7.65 with solid lead makes only a 3mm crater in the steel. The 5.56 with armor piercing steel cores makes a 4mm crater. The 50BMG with armor piercing steel core is so close to passing through we can see the hardened steel center of it pushing ~1.5cm through the back of the steel plate.
It makes a big difference. But if anyone ever says a 50BMG can shoot through a tank, remind them that the purpose of tanks is to have rifles not be able to shoot through them. Modern tanks sport more than 100mm of composite armor.
Photos courtesy of our excellent friend who goes by the name 'Chris' until he comes up with a better internet alias.
In considering the height, I decided to reduce the length of the legs segments to 4' each instead of 5'. That will put the maximum height of the leg sections at 8'. Along with a 5' cockpit/hip assembly and a 1' foot and ankle assembly this keeps the total walking height at under 14'. Which is the requirement of the US government to drive on the roads. I still have to work out how I'll get the feet to be so short, but I'll deal with that later.
It's also clear the changes have increased the efficiency of the legs. New efficiency is 8.0255. Stride of 6.33' with a actuator displacement of 0.79'.
What does that efficiency mean to us? We want to calculate the mech speed based on the stats we now know.
Lets start with the size of the actuators we're going to need. Assume the mech weights about 2,000lbs. At worst the leg will be at a 90 deg angle and the entire weight of the mech will be at a 4x leverage so each actuator will need to handle 8,000lbs. An actuator with a 3" diameter running at 1500psi will generate 10,602lbs of force so that will do.
At 3" diameter with a 0.79' total stroke per step we get 0.29gallons displaced per step. If we have an engine generating 5gal/s (~250lbs) this will make a step time of 3.48 seconds and a speed of 1.24 MPH. With a 10gal/s (~500lbs) engine this will be a step ever 1.74 seconds and a walking speed of 2.48MPH.
Of course, I also intend to have a 10gal accumulator. It will reduce in pressure as it drains so lets say I only get 5gal out of it at >1500psi. This works out to about 17 steps or about 109' before I'll be pulling from the engine again. There's no way to know exactly how fast a sprint will be at this point because that depends on just how quickly the actuators can fill and move. It may also depend on controlling the momentum of the device as we don't want the mech falling over when it stops.
The mech simulations take a while. I have some larger, longer ones going but this is an initial one. I'm working on cleaning up the documentation and making sure all the tests work just fine so that I can had it to the wider world cleanly.
The stats of this simulation:
The act of walking goes by a series of hard coded steps. I'm just asking the simulation to search out and find parameters for it.
Init: right foot forward, weight centered between feet (rtinit, rcinit, ltinit, lcinit)
The left leg is now able to take the weight
I've gotten the basics of a system to empirically build efficient walking. Right now it's only criteria are that it cannot pass through the ground and that it must be at least 7' tall at it's lowest height.
This particular simulation still has a foot collision that you can see any it takes a stride that's dangerously long. I've spent quite a while working on a zero-approximations collision detection system that I'll be turning on next.
I had to work a few more bugs out of the location computing and rendering systems. I think the image is still flipped but I'll deal with that later.
For now, I have the legs and hip sections modeled. Not just their current location, but even their kinematics are modeled in this rendering system: If I adjust the actuators the entire structure will move and react. And all in about 70 lines of code, including constants and comments.
#Leg attributes
actThighInit = 1.0
actCalfInit = 1.0
actHipDis = 1.0
actThighDis = 1.0
actKneeDis = 1.0
actCalfDis = 1.0
thighLen = 5.0
calfLen = 5.0
legBoneDis = 2.0
hipWidth = 8.0
#DISPLAY PROPS
leftLegDispProp = displayProperties([100,100,255],2)
rightLegDispProp = leftLegDispProp
actDispProp = displayProperties([255,255,100],4)
hipDispProp = displayProperties([255,100,100],2)
leftHipBack = location(0,0,0)
leftHipActuator = location(actHipDis,0,0)
self.struct = structureSeed(leftHipBack,leftHipActuator)
s = self.struct
#LEFT LEG
leftThighActuator = s.addJoint(leftHipBack,actThighDis,leftHipActuator,actThighInit,location(0,1,0),'f',dispPropA=leftLegDispProp,dispPropB=actDispProp)
leftKneeBack = s.addJoint(leftHipBack,thighLen,leftThighActuator,dispPropA=leftLegDispProp)
leftHipFront = s.addJoint(leftHipActuator,legBoneDis+actHipDis,leftHipBack,dispPropA=leftLegDispProp)
leftKneeFront = s.addJoint(leftHipFront,thighLen,leftKneeBack,legBoneDis,leftHipBack,'f',dispProp=leftLegDispProp)
leftKneeBrace = s.addJoint(leftKneeBack,math.sqrt(1.0+legBoneDis*legBoneDis),leftKneeFront,1.0,leftHipBack,'n',dispProp=leftLegDispProp)
leftKneeActuator = s.addJoint(leftKneeBrace,math.sqrt(1.0+actKneeDis*actKneeDis),leftKneeFront,actKneeDis,leftKneeBack,'f',dispProp=leftLegDispProp)
leftCalfActuator = s.addJoint(leftKneeActuator,actCalfInit,leftKneeFront,actCalfDis,leftKneeBrace,'f',dispPropA=actDispProp,dispPropB=leftLegDispProp)
leftAnkleFront = s.addJoint(leftKneeFront,calfLen,leftCalfActuator,dispProp=leftLegDispProp)
leftAnkleBack = s.addJoint(leftAnkleFront,legBoneDis,leftKneeBack,calfLen,leftKneeActuator,'f',dispProp=leftLegDispProp)
#HIP
legHipSupportLen = 1.0
legHipWingLen = 0.5
hipPostLowerPoint = 0.1
hipPostUpperPoint = 1.0
hipCockpitDis = 1.0
cockpitWidth = 6.0
actHipInit = sqrt(sq(hipCockpitDis)+sq(actHipDis))
# Main leg supports
leftHipSupportBack = s.addJoint(leftHipBack,legHipSupportLen,leftHipActuator, sqrt( sq(legHipSupportLen) + sq(actHipDis)),leftThighActuator, sqrt(sq(actThighDis)+sq(legHipSupportLen)),dispProp=leftLegDispProp)
leftSupportAttachFront = s.addJoint(leftHipFront,actThighDis,leftKneeFront,dispProp=leftLegDispProp)
leftHipSupportFront = s.addJoint(leftHipFront,legHipSupportLen,leftHipBack, sqrt(sq(legBoneDis)+sq(legHipSupportLen)),leftSupportAttachFront, sqrt(sq(actThighDis)+sq(legHipSupportLen)),dispProp=leftLegDispProp)
# Hip post
leftHipWingBack = s.addJoint(leftThighActuator,sqrt(sq(actThighDis)+sq(legHipWingLen)),leftHipBack,legHipWingLen,leftHipFront,sqrt(sq(legBoneDis)+sq(legHipWingLen)),dispProp=leftLegDispProp)
leftHipPostUpper = s.addJoint(leftHipBack,hipPostUpperPoint,leftHipFront,sqrt(sq(legBoneDis)+sq(hipPostUpperPoint)),leftHipWingBack,sqrt(sq(legHipWingLen)+sq(hipPostUpperPoint)),dispProp=leftLegDispProp)
leftHipActuatorPost = s.addJoint(leftHipBack,sqrt(sq(hipPostUpperPoint)+sq(actHipDis)),leftHipActuator,hipPostUpperPoint,leftHipPostUpper,actHipDis,dispProp=leftLegDispProp)
# Hip center
leftHipCockpitUpper = s.addJoint(leftHipPostUpper,hipCockpitDis,leftHipActuatorPost,actHipInit,leftHipBack,sqrt(sq(hipCockpitDis)+sq(hipPostUpperPoint)),dispPropA=actDispProp,dispPropB=hipDispProp,dispPropC=hipDispProp)
leftHipCockpitLower = s.addJoint(leftHipCockpitUpper,hipPostUpperPoint,leftHipBack,hipCockpitDis,leftHipPostUpper,sqrt(sq(hipCockpitDis)+sq(hipPostUpperPoint)),dispProp=hipDispProp)
rightHipCockpitUpper = s.addJoint(leftHipPostUpper,cockpitWidth+hipCockpitDis,leftHipCockpitUpper,dispProp=hipDispProp)
rightHipCockpitLower = s.addJoint(leftHipBack,cockpitWidth+hipCockpitDis, leftHipCockpitLower,dispProp=hipDispProp)
rightHipPostUpper = s.addJoint(rightHipCockpitUpper,hipCockpitDis,rightHipCockpitLower,sqrt(sq(hipCockpitDis)+sq(hipPostUpperPoint)),leftHipCockpitLower,'f',dispProp=hipDispProp)
rightHipBack = s.addJoint(rightHipCockpitLower,hipCockpitDis,rightHipCockpitUpper,sqrt(sq(hipCockpitDis)+sq(hipPostUpperPoint)),leftHipCockpitUpper,'f',dispProp=hipDispProp)
# Hip post
rightHipActuatorPost = s.addJoint(rightHipBack,sqrt(sq(actHipDis)+sq(hipPostUpperPoint)),rightHipPostUpper,actHipDis,rightHipCockpitUpper,actHipInit,dispPropA=rightLegDispProp,dispPropB=rightLegDispProp,dispPropC=actDispProp)
rightHipActuator = s.addJoint(rightHipActuatorPost,hipPostUpperPoint,rightHipBack,actHipDis,rightHipPostUpper,sqrt(sq(hipPostUpperPoint)+sq(actHipDis)),dispProp=rightLegDispProp)
#RIGHT LEG
rightHipWingBack = s.addJoint(rightHipPostUpper,sqrt(sq(hipPostUpperPoint)+sq(legHipWingLen)),rightHipActuator,sqrt(sq(legHipWingLen)+sq(actHipDis)),rightHipBack,legHipWingLen,dispProp=rightLegDispProp)
rightThighActuator = s.addJoint(rightHipActuator,actThighInit,rightHipBack,actThighDis,rightHipWingBack,sqrt(sq(legHipWingLen)+sq(actThighDis)),dispPropB=rightLegDispProp,dispPropA=actDispProp,dispPropC=rightLegDispProp)
rightKneeBack = s.addJoint(rightHipBack,thighLen,rightThighActuator,dispPropA=rightLegDispProp)
rightHipFront = s.addJoint(rightHipActuator,legBoneDis+actHipDis,rightHipBack,dispPropA=rightLegDispProp)
rightKneeFront = s.addJoint(rightHipFront,thighLen,rightKneeBack,legBoneDis,rightHipBack,'f',dispProp=rightLegDispProp)
rightKneeBrace = s.addJoint(rightKneeBack,math.sqrt(1.0+legBoneDis*legBoneDis),rightKneeFront,1.0,rightHipBack,'n',dispProp=rightLegDispProp)
rightKneeActuator = s.addJoint(rightKneeBrace,math.sqrt(1.0+actKneeDis*actKneeDis),rightKneeFront,actKneeDis,rightKneeBack,'f',dispProp=rightLegDispProp)
rightCalfActuator = s.addJoint(rightKneeActuator,actCalfInit,rightKneeFront,actCalfDis,rightKneeBrace,'f',dispPropA=actDispProp,dispPropB=rightLegDispProp)
rightAnkleFront = s.addJoint(rightKneeFront,calfLen,rightCalfActuator,dispProp=rightLegDispProp)
rightAnkleBack = s.addJoint(rightAnkleFront,legBoneDis,rightKneeBack,calfLen,rightKneeActuator,'f',dispProp=rightLegDispProp)
rightSupportAttachFront = s.addJoint(rightHipFront,actThighDis,rightKneeFront,dispProp=rightLegDispProp)
rightHipSupportFront = s.addJoint(rightHipBack,sqrt(sq(legBoneDis)+sq(legHipSupportLen)),rightHipFront,legHipSupportLen,rightSupportAttachFront,sqrt(sq(actThighDis)+sq(legHipSupportLen)),dispProp=rightLegDispProp)
rightHipSupportBack = s.addJoint(rightHipActuator,sqrt(sq(actHipDis)+sq(legHipSupportLen)),rightHipBack,legHipSupportLen,rightThighActuator,sqrt(sq(actThighDis)+sq(legHipSupportLen)),dispProp=rightLegDispProp)
I've got the new 3-d rendering system online, rendering, and exporting images. The image shown here was built using the code below
The first three lines of this code are the basic bootstrapping. We put two locations in space. We build out structure seed from that. I then define a display property to be able to highlight one of the spans. Then, the first two 'add joint' commands are using the 2D building ability. When building an object from only two points, I have to make up a third one in order to define what plane the new point should be in. I also need to say 'far' or 'near' relative to the made-up point that defines the plane since there are usually two possible solution points. The last 'add joint' is a regular 3D joint, made from three of the other joints.
You might notice that we constructed this pyramid without all of the pieces. In designing machines, this will actually be a valuable feature since it prevents you from making machines that *can* bind. This way, you must make models that are minimally determined and thus maximally able to move when their joints move.
nearL = location(0,0,0)
nearR = location(1,0,0)
s = structureSeed(nearL,nearR)
highlightDisProp = displayProperties([100,100,255],7)
farL = s.addJoint(nearL,1,nearR,math.sqrt(2),location(0,0,1),'f')
farR = s.addJoint(nearL,math.sqrt(2),nearR,1,location(0,0,1),'f')
top = s.addJoint(nearL,1,nearR,1,farL,1,dispPropA=highlightDisProp)
Lastly, I've uploaded the code for this. It requires both pygame and imagemagick (just to apt-get installs on them). Run the command 'python main.py' to make it do it's thing.
https://docs.google.com/open?id=0B1S9HNoTaV32Y20wRjVhNzBfd0U
I needed a 3D simulator. There are lots of programs that let you draw objects and place them. I didn't see offhand any that have the simulator compute the locations of things based on their distances from other things. And it would have taken me a while to find the right one with the right APIs so I just didn't.
Instead I'm making a 3D simulator. Like the 2D version I already made it computes locations based on relative distances from other locations. I've added compatibility with 2D as well as lines for convenience.
Today, I got it computing locations even for the complex 3D cases. The interesting part of this was doing a bunch of rotations until the points were in a plane where I could compute the solutions to them.
I solve the problem in two major parts. Each part is essentially solving for the intersection of two points. So let's say I have joints A,B,C and distance dA,dB,dC from the new joint D that we're going to place. I start with joint A and joint B. I solve for where D is relative to them. But in a 3D world that's actually a circle. Based on the location of C and dC I can find a specific point on the circle D. Below are the exact steps:
If you spend a few minutes thinking about this, you'll notice that the points and distances is not enough to determine an exact point. It determines one of two points. As with the 2D system, I'm solving this by using the right hand rule. If you list the points clockwise from your perspective, whatever perspective you choose, the plane those points in will be between you and the new point. Take a sec to think about it.
To give an example test case I run:
#Test case: 3D joint
j = joint()
j.jointA = location(1.0,0,0)
j.jointB = location(0.0,1.0,0.0)
j.jointC = location(0.0,0.0,1.0)
j.spanA = span(1.0)
j.spanB = span(math.sqrt(1+1+1))
j.spanC = span(1.0)
j.computeLocation()
if(j.x > 1.01 or j.x < 0.99 or j.y > 0.01 or j.y < -0.01 or j.z > 1.01 or j.z < 0.99):
\t p = False
\t print "ERROR on test case 8: %s"%j.toString()
I've decided to call the new rendering and computing engine MindFuck3D. From this post, I hope you can begin to see why. Once I try to actually design in this new language I think it will really win it's name. It will be difficult to get good at but very quick and powerful once I have it down.
I've added color and sequencing to the simulator. I've also added a cockpit (red) and an engine (grey) to the mech to show better what it will look like.
The simulator is good enough to be able to simulate many possible walk sequences. I wrote a function that tries many many actuator combinations to come up with a walk sequence that fits a few basic criteria:
I then fed the computer-chosen result through a function to show the sequence and spit out some diagnostics about the walking movement:
I noticed in the course of doing this that the certain actuator positions increased efficiency. However, I suspect they also rely on greater actuator strength. Right now I'm counting all actuator displacement to be made equal. In reality, the difficult of moving the actuator isn't just in the distance it travels but also the force on it. To compute this function automatically I'll have to add a ton of statics equations to the simulator.
Notice that in addition to the simple walking sequence I've added the crouch distance. For this configuration it stands with a hip height of 8.7' and a minimum crouch distance of 4'.
