View Full Version : Onyx X build thread

02-06-2017, 06:59 PM
The upcoming Robogames kicked me in the butt enough to dust off my Onyx X plans.
You may recall, I was too busy with the robomagellan last year, and couldn't get Onyx in shape.
This time, I'm prioritizing the other way around -- magellan is standing aside, and I'll re-build Onyx based on learnings from before.

I have a bunch of interesting things I'd like to try, from "stabilized turret based on belts and brushless motors" to "on-board aim assist with Raspberry Pi," but in order to make it to this year, I've decided to hold myself to the simplest possible scheme.

Main problems to solve:
1. read-back of stats over XBee just doesn't work -- it is so slow turning around the on-air interface
2. the frame was really narrow and couldn't fit the target plates. This was great for maneuverability.
3. also, the frame took a bad fall, and is a bit twisted
4. the 5 GHz video would fade in and out, and all monitors I have at home cut out when sync isn't perfect
5. the head/turret would shake around more than I like when walking -- it was fairly top heavy
6. screws would come lose and be left on the floor all over when walking too fast
7. various bits (including the camera lens!) shattered from the airsoft pellets

Planned solutions:
1. I will build just a forward control this time, and if I have time left over, send read-back using another mechanism (second Xbee, WiFi, etc) Keep It Simple Stupid!
2. I can spare an extra inch in width/height to put the plates on the body.
3. I'll have to build a new frame to solve the space problem, so Tormach mill, here I come!
4. I'll throw money at this problem and buy a drone-approved video display that presumably doesn't lose composite sync from noise
5. Moving the plates off the turret will help. Also, while two guns looks awesome, I'll go for a single gun this time.
6. Threadlocker, every screw, every time. There is no such thing as "just testing and I'll do it better later" -- do it as if it's final every time.
7. Delrin is easily laser-cuttable, and can also be heat-strip-bent in a pinch. 1/32in delrin sheet is cheap and doesn't weigh too much. I'll build a shell of Delrin, and then add some 1/32 transparent polycarbonate around the bits that need visibility (camera, indicator LEDs)

Also, the previous body was smaller, and needed the turret heading servo to be mounted on top of the top plate, which meant the turret was high up, contributing to the jittery balance. This new body puts the servo in the same plane as the hip heading servos, inside the body. This leads to a lower center of gravity.
If I have time, I may build the infrastructure to support the turret with an external thrust bearing, but for now, the thrust washer on the heading servo will have to take the load. Because the servo is advanced from center of body, this means it may take some radial load, which is not great. Or I'll move center of gravity forward, and adjust the gait to compensate.

I'm thinking I'll post pictures here as things develop, to keep me honest and on-track. If anyone actually bothers reading and sees me deviating from the KISS principle, a swift kick would be much appreciated!

02-06-2017, 07:40 PM
First pictures:

I've used to use Inventor for my mechanical drawing, but was recently turned on to Fusion 360.
I tried an early version many years ago, and didn't like it, but Ah-mah-gerd! It's great now!
Integrated CAM, straightforward simulation set-up, sketch mode flows smoother than Inventor, and yet it seems to share a lot of genes with it. Oh, and it's free. What's not to like?



You may be able to see that there's a version of the tibia that bolts one slot (22 mm) higher up on the knee servo.
In that configuration, the toe of the tibia is higher up than the hip elevation joint. This means there would be a minimum distance away from the mech that I could touch down, and the femurs would have to splay out a lot when getting really close.
However, that mechanism may actually end up being more nimble in actual walking -- we'll see.

And how do I make the pictures be appropriately wide for the post? Right now you see the left half of each picture ...

02-06-2017, 09:27 PM

Looking good.

Looks like you have a lot to do. Let us know if there is anything we can do to help... even if its just moral support.

02-07-2017, 03:56 PM
Moral support would be great :-)

Machining very thin, large objects is hard for me -- about 6 inches is the max size, and the new plates are more like 8x8.
I'm thinking of sending them off to Big Blue Saw. Or maybe I'll just use 3/32" Delrin for those plates off the laser...
(I tried using the waterjet at Tech Shop, but the aluminum sheet I have "bubbles" during pierce-through; looks like de-lamination.)

The other thing I'd love to have is better situational awareness. At least distance sensors for either each of the sides, or each of the legs, so I know if I'm trying to walk into a building sideways.
But, that both requires a working telemetry system, AND additional parts to integrate. Firm NO on that!

02-07-2017, 04:24 PM
Looking good!

02-08-2017, 02:35 PM
Attempted last night to get a kogeto dot to also provide an image in the unused center of the optical assembly, but did not know enough about its construction to get it working quite right. With some corrections, I hope it will be possible to add an external flat mirror above the center to get a plain directional view in the center of the panoramic view. If not, I might try making a simpler (3D printed?) version with only a single top-mounted convex mirror for downward looking panoramic view (very good view of robot) and a single flat mirror above the hole in the center of the convex mirror.

Have not chopped the optics in half (cross-sectioned) to be absolutely certain, but it appears to be a single injection molded assembly with two molded plated/silvered rear-surface mirrors and a large molded lens that forms the dome of the assembly. The larger mirror is concave and nearest the final corrective lenslet. The smaller mirror is convex and in a crater at the top of the large dome lens. So quite certain that the rays go through the lens to the larger concave mirror on the opposite side then reflect to the smaller convex mirror then reflect through the un-silvered center of the larger concave mirror to the lenslet that mates to the larger molded optical assembly.

The internal thread of the protective housing not only connects the housing to the phone bracket but also holds in the retaining plate for the actual optics, so you can just unscrew the plate instead of breaking apart the protective housing like I did. After disassembly, I removed a small circle (~2mm) of the mirror plating from the center of top dome. I went too deep with a plain drill bit hoping the optics were hollow and I would simply end up with a hole in a mirror surrounded by air, so I absolutely have to clean, polish, and backfill the hole with some sort of resin to restore the full vertical range of the panoramic view and then try to make that resin form the final corrective lens in the recess of the convex top mirror. Also have to repair some of the larger concave mirror that lost its silver, so might just try again with a new kogeto dot.

If you can produce a sufficiently polished surface with the cutting tool, then it should only need a small lenslet for final correction. I'm thinking a much better solution is to simply get a de-silvering agent to easily remove a small patch from the center of the top mirror and avoid the need to perform any surface polishing (if actual silver coating (http://angelgilding.com/silver-remover.html) or if aluminum coating (http://angelgilding.com/aluminum-remover-125-ml.html)).

02-08-2017, 10:00 PM
I think you'd need some lapping and/or polishing to get good enough surface. Raw machining doesn't do it. (Well, unless you have a super nice face mill and only need it to be flat.)

Separately: I was going to build the host board for the OpenCM (so I don't have 10 little boards for hosting power / Xbee / voltage conversion / etc) and looked to re-install the Eagle I have paid for. But now, Autodesk owns it, and charges $500/year for the ability to make 4 layer boards. And killed the Maker version. So, KiCad, here I come! (one yak already! eek!)

02-09-2017, 12:14 PM
I have some time on the mill later today, to bang out the femur brackets. (8 total; two per leg)

I realize that the femurs might make the legs more rigid if I use some kind of connection between the two sides, but with the necessary clearances for full movement, there's not a great way of achieving that.

Also, the femurs in the picture above are 140 mm center-to-center. The ones I used on Onyx 3 were 80 mm, and I think those were too small -- the servos can lift more, and I can get some more speed out of them with a longer femur.
However, 140 mm seemed too much when doing some calculations on the IK and reach, so I decided to split the difference, and make them 110 mm for this go-around. Assuming the brackets come out usable today, I will be using them in April; no time to change too much!

I make these out of 1-1/4"x1/8" 6061 aluminum bar, which is almost the perfect size already. I'm planning to skim 0.08" from top and bottom to get a good finish (assuming it's flat enough!) for a total thickness of 3mm. This is thicker than I used before, but static simulation says a thinner femur will reach cracking strain if loaded by 6 kG alone. That's unlikely to actually happen on this bot, but I like safety margins. The thinning slots in the femur remove weight, at least!

I will have to make the outer servo connect to the tibia at 90 degrees to make sure I have clearance to move the femur straight up. I already did that for the 80mm version, so that's OK.
I may experiment with making the bottom servo also stick out at 90 degrees. The 80mm version had it in the upside-down position as in the picture above, and that works OK, but maybe I'll try putting that at 90 degrees, too. The Robotis C-bracket driven by the hip heading servo is already adding radius from the hip, though, so that extra inch may be a bit much, especially given that the body is now wider as well. We'll see!

02-09-2017, 12:53 PM
Could add some reinforcements to opposite sides of the femur (a little bit of C-channel on the body-side on top by 'knee' pitch and foot-side on bottom by 'hip' pitch) as long as they are able clear the edges of the servos when fully retracted. Basically a tube with multiple cutouts for clearing the servos when the leg is fully retracted, like some of the leg frames of the DARwIn-OP.

02-09-2017, 04:14 PM
Yes, I've looked at that. Ideally, I find some pre-made U or rectangular extruded channel/tubing that can be milled to the dimensions needed.
47mm inner distance only gives 1.9mm each side if I make it out of 2" tubing, and the next step up is 2-1/2" and that doesn't come in thick enough walls, so then I'm looking at milling out of solid stock, which seems very wasteful.

And 2"x1/16" rectangular tubing is almost a millimeter too wide on the inside :-(
It's cheap enough that maybe I should get some to try out, though?

02-09-2017, 04:55 PM
Or try cutting sheet and bending it in a brake, just like how most of the other frames are made for bots. I expect that Fusion 360 has a sheet metal forming capability just like Solidworks. You can adjust the radius for each bend to make sure things line up and then unfold everything into a flat drawing ready to mill.

02-09-2017, 09:25 PM
Yes, I was looking at sheet metal, and tried some 5052 aluminum, but:
- on the waterjet, it delaminated on pierce-through
- on the mill, I get edges that are too rough -- 5052 is a pain to machine
- also, workholding of sheets on the mill is a pain. The least bad is mitee-grip wax paper, but it's not a slam dunk

The good news is, a few hours at the Tech Shop today came out really great for femur brackets (separate for the two sides, as in the picture):

The first step required one clamp and three tool changes per piece (2.7mm drill, 3/8" milll, 1/4" mill):

The second step required no tool change (it's all 3/8" milling) but two clamps per piece:


I didn't bother with soft jaws, so the second clamp was by eye only and a bit was sticking out of the vise and vibrating more than I'd like. But it got the job done :-)

(Other things you may be able to see:
- The first bracket, I had forgotten to add the cutout for the center of the MX-64 horn, so I did those by hand and they're bigger than the design.
- The third bracket, I clamped too hard in the vise so it buckled, and didn't get fully faced by the 3/8" endmill)

Anyway, a good use of three hours!

With soft jaws and a fly cutter instead of end mill for facing, these would have been perfect. But I'm not going for perfection :-)

02-12-2017, 08:47 PM
Alright, back to the actual build! I've been a good boy, and spent almost zero time looking at what it would take to build my own 433 / 916 MHz Xbee-like device out of the $2.80 Atmel parts ...

I've decided to build a single host board for plugging everything else in. Because I have 190mm of covered area inside the body, there's enough room for almost everything. Even a 4S battery. (Yes, I may go back to trying 4S this time! I'll develop on 3S, and if I feel lucky, pre-discharge the 4S to 16V or less, and run with that.)

So, the inside fits battery, controller (OpenCM 9.04,) power switch, control XBee, and scoring board, as well as the yaw servo for the turret. This will keep center of gravity lower, which is good for stability. I've lasercut 3/32" Delrin to fit, and figured out where all the screws go, so I'm ahead on that front, too.

Because of all the radios inside (I may add a third one, to get telemetry back, at least while developing) I will likely stay with the Delrin for the body.

I've learned KiCad, and the OSH Park submission seems to come out alright in the previews, so there is that. Also, DXF files exported from Fusion 360 somehow double up all the strokes, and I found a shortcut in how to remove the doubles in Illustrator. Select it all, then press "outline" in the Pathfinder tools. Magically, single outlines of all the paths are created! Great for lasering.

Tomorrow, Big Blue Saw starts a Valentine's sale, where 1/8" 6061 aluminum parts will all have the quantity discount applied.
Given all the radios I'm applying, I don't know whether I want aluminum, though. The turret will contain video transmitter, camera, and the gun, as well as the hit indicator lights. The body will contain everything else. Plastic seems better (but less rigid.)


02-12-2017, 11:59 PM
Nice parts! Do you plan to sandblast them?

02-13-2017, 10:42 AM
Onyx 3 was sandblasted and powder coated black. People thought the parts were plastic :-)

This time, I'm going for functionality; bare metal, no treatment. Two months to go!

02-15-2017, 09:58 AM
Good call. A working unpainted robot is better than a non-working painted robot.

02-15-2017, 11:17 AM
Iterating on the base plates using paper models and Delrin turns out to be quite effective. I think I have all the cable routes and standoffs and screws accounted for, now.

There's also a tension between "holes to make it possible to poke at things without disassembling the robot" and "must be ruggedized against an incoming onslaught of plastic pellets." I may put more holes on the bottom, and less on the top, perhaps. (Except the top is where the wiring to the turret needs to be.)

Representative image: (yes, this process is messy! and involves kitchen tables!)


02-16-2017, 11:00 AM
I'm a careful fellow. I use simulation software for my machine tool paths. I run air passes so I don't crash the mill. I fix all compiler warnings in my software, and turn on as many warnings as I can. I run design checks in my electronics CAD. At least, that's what I tell myself.

Last Sunday night, pretty late, I was finishing up the main board of Onyx X, having just learned KiCad.
OSH Park actually allows you to just upload the kicad_pcb file to their site now; no need to generate Gerbers, so that's cool!
When dry fitting everything, I realized I had no 3.3V power connector for the aiming laser. Not liking to tap into other traces/pads with patch cables, I dropped a 2 pin header onto the board, into a free area of GND fill (and +12V fill on the top side) and routed 3.3V into it, and sent it off for the Monday morning board run.

I opened up the board yesterday to check something out, and pressed the "DRC" button. Which I had forgotten to do after the final adjustment last Sunday. Here's the story in three pictures:




The solution will be to Dremel out the copper around that pad on the top layer before I do anything else when I get the boards back. Here's hoping I remember to do that! And test continuity.

Now, I got this in 1.6mm 1oz copper. Fourteen servos plus a bunch of radios actually draw a fair bit of power, at least at peak, so I may want to re-spin it on 0.8mm 2oz copper anyway. The idea was to fit everything, and make sure it works, and then get that next order in and finished before RoboGames mid-April. There will still be time, but it might be tight ...

02-16-2017, 11:41 AM
Ouch! Been there :o

I have not learned KiCad yet - still using Diptrace. So I still have to generate Gerber files. So I run the diptrace verify functions first, then generate gerbers and then I run viewmate (older version) by pentalgix to make sure that the gerber generation did not totally screw up.

But I still miss some!

02-16-2017, 02:14 PM
So far, KiCad has very few annoyances, and mostly works great!

Forward- and back-annotation is not automatic between schematic and PCB layout, though -- you have to press about three buttons to go each way -- which is the only real annoyance I've found.
I can think of large projects with many enginers where a carefully staged process for going back and forth would be useful, but forcing it on everybody seems clunky.

Also, when I moved parts around into hierarchical sheets, they got re-numbered (more accurately, the numbers got set back to ?, and I auto-renumbered them.)
Then, when going through "export netlist" -> switch -> "import netlist" all the nets ended up being screwy, because "pad 3 of J5" was something totally different now.
There actually exists a solution for this in KiCad; you can associate parts by "timestamp (id)" rather than "name," which would have solved this, but it's not the default, and I didn't know/realize I had to use it.

Power tools, indeed.

03-07-2017, 11:24 PM
Progress is being made.

The boards came back, and I could Dremel out the bad connection. Unfortunately, I initially created the footprint for the main power screw terminal with too small (default) through holes. I updated the footprint before I sent the boards off, but apparently forgot to merge that update into the actual board -- something KiCad doesn't do on its own. Thus, I couldn't fit the power connector into the holes without shaving down the pins.

Everything else so far seems to work, so that's good. Except I had assumed 3mm resistors all around, but the parts box only contains 6mm parts for some values I'm using, so I have to inventory those and make a Digi-Key order for the final version.

Another thing I've noticed is that, when running with 16V supply, the electrolytic capacitors on top of the OpenCM-9.04 run very hot. My guess is that's not actually ripple current, but heat that goes through the vias/leads from the power regulators, which are linear. The maximum input voltage for the regulator is 20V, but the input capacitor is only rated at 16V, and the output is rated at 6V. Given that a 4S battery maxes out at 16.8V, I think that's quite marginal! (Similarly, MX servos are rated for "4S input" but they declare over-voltage if the voltage goes over 16V.)

The OpenCM draws a fair bit of current as these things go, so using a linear regulator to drop from 16V down to 3.3V (as well as 5V) generates a lot of heat! Maybe it's their way of feeling like MechWarriors :-)

Options on the table:
- Let it run like this; heat just makes the electrons flow faster, and nothing should live forever!
- Drop an adjustable linear regulator into the board, pushing perhaps 7.5V into the OpenCM board ++ pins. (Power for the DXL already runs through fat separate traces.)
- Drop a switching regulator onto the board, similarly pusing perhaps 7.5V into the OpenCM board, with less wasted current.

Most of the time was spent clearing up the workspace so I could actually solder up the board, though. After all was said and done, four full trash bags of junk and old finished or failed projects made it towards the landfill and metal recycling (!)


03-07-2017, 11:27 PM
This is the current leader among the options. Remains to see if I can find the board space in a good spot.


03-09-2017, 09:30 PM
I verified Xbee connectors work, and gun management works. I can run with or without the IR cycle sensor, and it's obviously better to run with! (But if it dies, it will still fire pellets)

I structured my Xbee protocol to use very small data packets (5 bytes!) and to send the response with status (if any) right after I get an incoming packet, and so far, that doesn't cause the sluggishness in turning around the direction of the link that I would see before with larger packets and asynchronous sending either way. I may still be able to get telemetry! Yay!

I fixed the bugs in the board (too small power connector holes; laser 3V connector placed right through main power trace; OpenCM needs a lower voltage in to avoid heating up; 900 MHz Xbee modules do not want an LED on RSSI) and sent off to OSH Park for 2 oz, 0.8mm boards. The thicker copper will have less resistance for the current I draw, although I designed it to allow > 10A everywhere even with 1 oz copper (using top/bottom pours and paying attention there's no tight choke points.) So far, so good!


And, yes, I think I have all the parts needed to put the full robot together. Just taking it easy, one subsystem at a time.

03-12-2017, 05:43 PM
I designed the carrier board for the OpenCM 9.04 because that's what Onyx 7 used.
It used it, because I wanted to use the Dynamixel library from Robotis.
However, now that I'm back in the code, I realize that I ditched that library and use my own code, just re-using their low-level functions for switching the TTL bus direction and talking to the USART.
So... I might just as well have used a Teensy! But too late to change now.

And, to be fair, using the OpenCM means I don't have to add a 74HCT125 to the board. That's a big win ;-)

03-19-2017, 08:38 PM
Still a pile of parts ... most robot time has gone to help my daughter with hers, and re-cutting the femur brackets, because the countersink for the screw heads was 0.3 mm too deep and the bottom of the screws bit into the plastic below the horns when torqued.
(Using 1mm shorter screws means too little engagement in the horns.)

At least I have one femur mounted now! I'm halfway done cutting the new tibias, too (with cavity to mount a 1/2" steel ball for a toe.)

Rev 2 of the PCB is still at OSH Park; it's 2 oz thickness so that'll be good for current.
Still don't know if double 0.1" delrin plate is stiff enough, or whether I'll need to cut some aluminum in the end. I'm hoping for the Delrin.


I've also worked on the remote control some more. So far, it's looking as if I can actually get a few bytes of telemetry back each frame, without the ongoing stuttering that I've been having previously, by carefully scheduling the on-air packets to never overlap.
I'm also using "S3B" 900 MHz modules, which claim to go all the way up to 20 kbit/s on air. (The pre-2016 ones only do 10 kbit.) No idea whether that means they are more susceptible to interference.

Finally, broke down and ordered a FPV-specific display from Amazon. It clearly states that it doesn't go to black/blue screen, so presumably it will display whatever's there even if it's noisy, which was the problem with all the other displays I've tried. (And, thinking back on it, actually was the main unsurmountable obstacle in my mind, keeping me away from re-starting the project earlier.)
This thing didn't exist two years ago: http://amzn.to/2mGvYkl

03-20-2017, 03:37 AM
Very cool! Nice beefy servos! Won't you have traction problems with a steel ball for a foot?

03-20-2017, 11:02 AM
This is actually a re-build of the 2014 Onyx, with some changes.

The main problem has not been slipping, but instead snagging on carpets and such! When going fast, if a foot gets stuck, it makes a very pretty pirouette, because of the high rotational leverage and low rotational damping of only two ground contacts.

Now, if the floor is a glossy sheet of Delrin or oil Nylon or something, I'll be in trouble. Better bring some Shoe Goo and sand paper for that eventuality ;-)

Here's the old version.
The new version will have only one gun; cutting down on weight!
It also will have wider clearance between the legs, to make sure there's space for the scoring panels.
I had to mount them on the head last time, and that made it very top heavy.
The agility of a 125 mm hip axis baseline was great, but I don't need that much (see "pirouette" above :-) so I'm going with 180mm this time. I'm also going with 100 mm femurs instead of 80 mm, which will give longer stride length, but also will make it wider. Here's hoping the new arena really sticks to the 3 foot lane width!


03-21-2017, 04:23 PM
I tried to cut the new tibias with room for 1/2" steel balls today. It did NOT go well.

First, I found a bug in the Mach3 post processor for Fusion 360. It generates code around tool changes that may make a tool crash into the work, because it applies the tool length offset AFTER it already does the first movement to position over the next entry.
This was my first carbide endmill and work piece lost today.


Second, the Tormach Tool System uses a special kind of collet that fits in a 3/4" R8 collet, to allow for automatic tool changers, as well as precise positioning relative to the spindle with a second contact surface perpendicular to the table. However, when pushing the mill a little bit (not overloading, just pushing a bit) there's significant risk of pull-out on the collet, seemingly no matter how much you tighten the drawbar.
If the toolpath goes close to the vise jaws (hardened steel) and the bit is suddenly 1-2mm lower than you previously measured and set it as, sparks will fly.
This was my second carbide endmill and lost workpiece today.


At that point, I gave up in disgust and went to work.

03-21-2017, 05:26 PM
Mostly this hobby is tons of fun. Sometimes it's not...

03-25-2017, 11:31 AM
The new boards came back. 2 oz copper, for additional current capacity. This makes the through-holes slightly narrower, which with the default hole sizes in Eagle CAD used to not be a problem. The default hole sizes in KiCad are narrower, and I had to really force some leads through the holes. Even with 1 oz copper, those narrow holes would make a PCB trouble for a through-hole pick-and-place machine, so I don't quite understand why they have it like that?

Anyway, the new board uses a Pololu 6V switching regulator to power the input of the OpenCM, to avoid the significant heating in the linear regulator they use at 12V (or, worse, 16V.)
The regulator Robotis uses on the OpenCM is rated at 0.8V drop-out typical, 1.0V max, so 6.0V seemed like the right choice for a 5V rail.
However, even though the Pololu regulator outputs 6.06V, the OpenCM board does not start up with that voltage. I wonder if this is some code in the firmware/bootloader that attempts to prevent people draining their 2S LiPos, or whether it's some built-in UVLO, or what. I'm going to short the regulator with a 5V Zener for now, and if I spin the board again (I hope not!) I'd go for a 7.5V switching regulator output.

It's always something.

In other news, I'm going back to the shop to mill the tibias today, using significantly less aggressive toolpaths (never going above 0.08 HP of the spindle, never deeper than 1/8" with a 3/8" mill, no faster than 280 sfm, and such...)
Wish me luck!

03-26-2017, 02:12 AM
Good luck!

Regarding regulators, Pololu makes several regulators with the same form factor, so maybe you could just swap regulators? I'm using their D24V50F5 5v regulator, mounted with a pin header on the regulator and those really tight round-hole pin sockets on the main PC board.

I'm socketing the expensive or likely-to-get-ganked parts like the regulator and stepper drivers. I haven't yet decided whether to solder the Teensy on or use a socket...

DipTrace has all kinds of settable defaults for vias and thru-hole sizing. Maybe Eagle does as well?

03-26-2017, 11:55 AM
I had to find enough space on my board, so I mounted it under the already-socketed OpenCM without a socket.
I lined up the through-holes and soldered a bit of wire right through. It actually worked out great from a mounting point of view, as the smaller Pololu regulators are totally flat on the bottom, but with the supper-grippy ENIG we get from OSHPark, de-soldering is quite a challenge :-(

Anyway, the 5V Zener seems to be doing its job (it's a 1W part, so rated for 200 mA) and drops the input voltage from 13-16V to 8-11V, which is better than a kick in the teeth.

My next challenge is that the top voltage for the MX-64 is 16.0V, and a fully charged 4S is 16.8V, so the servos blink with the overvoltage warning when I turn them on. I'm considering building something with a MOSFET and an inductor to pre-condition the battery down to 16V after charging...

In other news, laser-cut black delrin cleans up nicely with some dish soap! And I bonded the 1/2" steel balls to the bottom of the new tibias. The new tibias came out well, except the vise for the final bottom facing operation clamps hard and slightly bent the mounting flages inwards, so they're a little too snug to actually screw on until I bend them back. I didn't make soft jaws because you may have noticed I'm short on time :-D

To avoid having to wear out the battery connector turning the thing on and off, I have my favorite power control: A rocker switch with "safe" and "armed," and a momentary pushbutton "on" switch. The "safe" just disconnects the P-FET gate from any path to ground, so the pull-up resistor keeps it shut off. Once it's "armed," the pushbutton parallels a small N-FET that's controlled by the microcontroller, so the microcontroller boots up, detects that the voltage is OK, and keeps it on. Once it detects the battery is depleted, it turns off the N-FET and the whole robot turns off, saving the battery from extinction. I've used this in a few other designs, and it's the bee's knees!




03-26-2017, 12:00 PM
And before you ask, yes, I'm deathly afraid that the epoxy bond will give out and the spheres will come off.
If this doesn't work, I'm considering drilling a hole through the spheres and putting a M2 screw through them and the tibia.
I'd need a little more depth in the mount, though, but luckily these particular parts are not that hard or expensive to re-cut, just time consuming. (Assuming the software and hardware cooperates, that is!)

Also, I promised a second robot. Here it is being built!


03-26-2017, 12:01 PM
The robot is the one on the left, in case there's any confusion.

03-28-2017, 10:22 PM
The 5.6V Zener I used to drop voltage for the OpenCM died, and I was back to the Pololu 6V switching regulator not starting up again.
I tried first starting up the board, and then plugging in the OpenCM, but it still didn't work. There's got to be something with the OpenCM that makes this not work (large input cap, plus some feedback in brown-out detection, is my guess.)

I tried a TO-92 7806 I had laying around instead. It's limited at 100 mA, and it turns out the OpenCM draws 130 mA.
130 mA for a microcontroller board!!! I know that the TTL buffer needs some, and the CPU is reasonably fast, but that's a lot.
This would be why the Zener died, I guess. It's rated for 1W, but 6 Volts times 130 mA is getting right up there... And maybe it's not 1W continuous.

After de-soldering the 7806 and the Pololu regulator, the pads on the board were all lifted out, and I couldn't use them for a third solution.
(This is surprising, as I've generally seen higher quality from OSH park. This is the 0.8mm / 2 oz board, though; perhaps that is different?)

In the end, I took a 400W 6.8V bidirectional TVS out of the parts bin, and jumpered it in between my 16V rail and the socket pins for OpenCM power, on the underside of the board. The part isn't rated for 400W continuously, but it's beefier than the Zener, and drops the voltage enough that the OpenCM doesn't overheat. The part itself also gets quite warm, but doesn't overheat (I had it on for an hour to be sure.)
Main drawback is that dropping 6.8V means I can't use a 3S LiPo -- I'm committed to the 4S path now!

In other news, I found a 5" display for a Raspberry Pi, that doesn't need a HDMI cable. It does this by re-using most of the RPi GPIO pins for a parallel TFT driver, and there's a simple hat-like pad that goes on top of the Pi to drive it:
I need the Pi to go from Xbox gamepad to Xbee control, and now also to display telemetry received back from the 'bot.

03-29-2017, 10:43 PM
Spent the evening working on wireless video.
I have a few transmitters (200 mW 5.8 GHz ones from HobbyKing) and receivers and cameras (a variety, again from HobbyKing.)
Also, a new composite video display that doesn't blue/black out when the signal isn't perfect. This was the main problem last time!

After shifting around and finding the matching channels on transmitter and receiver, I finally found that the camera I first used seemed to have kicked the bucket. This camera had been used before and worked -- it's a back-up rear-view type car camera, from Amazon.
Swapping out a more FPV-style camera, made the entire link work.
But the quality is still bad!

And, surprisingly, the higher-quality camera I have, had a much worse image than the cheaper camera with lighter lens.
Also, even with the lighter camera, white areas had a lot of black "spikes" in them. I presume this is because of clipping/distortion somewhere in the video path.

I'm also not 100% delighted about the kinds of connections that are used by these pieces of gear; loose single wires abound without any coax or even attempts at shielding.

Anyway, not a fantastic outcome, but I can see moving pictures enough to aim. Here's hoping I'll have two working transmitters/cameras for the two bots, or I'll have to print some hot-swappable armature to mount/dismount them, and hope we never get seeded head-to-head ...

If I were to throw money at this problem, and get a working, leightweight, camera + transmitter + receiver + display, with good quality, and ideally ready-made wiring harnesses, does anyone have a recommendation that is 100% plug-and-play, no muss, no fuss, and doesn't weigh a pound?

03-29-2017, 10:52 PM
Here's a thing... http://www.ebay.com/itm/Skyzone-SKY-HD01-5-8G-400mw-1080P-FULL-HD-FPV-Wireless-Transmitter-DVR-Camera/162413848467

03-29-2017, 11:07 PM
Also, this is a thing: https://www.readymaderc.com/store/index.php?main_page=product_info&cPath=4_318&products_id=6562

03-29-2017, 11:37 PM
The closest I seem to come to "plug and play" might be this combo:

http://amzn.to/2nim5JT -- monitor with receiver
http://amzn.to/2oAS60M -- camera with transmitter

They're even branded the same ("eachine") although whatever that means in this brave new world of cheapest-crap-of-the-month, I don't know.

03-30-2017, 04:15 AM
I see one of them requires a ham license. I was going to let mine expire this year - now maybe not!

If you find a good setup, let us know, will you?

03-30-2017, 11:32 AM
Yes, that is power based. We've generally decided that someone at the games needs to have a license to make sure people can use the more powerful transmitters. I recommend you keep yours :-)
However, for the twenty feet range we're talking about, 25 mW might be quite enough, and stronger transmitters lead to more multipath problems (image shadow) so I'm going to hope the 25 mW actually works well.

03-30-2017, 11:44 AM
We've generally decided that someone at the games needs to have a license to make sure people can use the more powerful transmitters. I recommend you keep yours :-)

By the way, I recently got an amateur technician's license for the sake of drone racing. In case it helps...

03-30-2017, 11:53 AM
If you're going to be at the games, it helps! :-)

03-30-2017, 12:56 PM
Ham Tech license is in renewal now - it expired six weeks ago. I'll have it in hand when I'm there on Saturday and Sunday. KB2CST...

03-30-2017, 10:16 PM
Yes, that is power based. We've generally decided that someone at the games needs to have a license to make sure people can use the more powerful transmitters. I recommend you keep yours :-)
However, for the twenty feet range we're talking about, 25 mW might be quite enough, and stronger transmitters lead to more multipath problems (image shadow) so I'm going to hope the 25 mW actually works well.

I have a technician license too, I'll be there the entire time.

My call sign is KI7CIS.

03-31-2017, 09:12 PM
So, an update: The Amazon micro-cam arrived, and the Amazon LCD with built-in receiver arrived. (Yes, I paid the $3.99 to get it next day. Running short on time here. :-)

They synced up easily enough. The transmitter/camera has a simple pushbutton band/channel selector, and the display has an auto-scan feature.

However, the quality was still poor -- lots of interference, like I've seen with the Hobby King stuff. Previously, I suspected my 802.11ac WiFi, but I've used a radio spectrum analyzer to make sure the channel is clear before using it, so that's not it.

Then I pressed the button on the receiver that turned on "diversity" (using both antennas to receive,) and, like magic, to image cleared up and was nice and steady!

So, I can report that these two things work together, and the camera is small enough to not encumber a 'mech much. The only problem I found was that the LCD is 16:9, and the camera is 4:3, and I couldn't find a way to make the LCD not stretch it sideways.

The camera has absolutely no mounting holes, so you'll be using tape or velcro or zip ties or, as we will be doing, 3D print a holder.
Also, although the camera is intended for drone flying, where crashing happens, I would put a thin polycarbonate shell in front of it, to protect it from BBs.
My previous camera lost a lens to the Boston team before; don't want that to happen during a match :-)

http://amzn.to/2nim5JT -- monitor with receiver
http://amzn.to/2oAS60M -- camera with transmitter

03-31-2017, 09:47 PM
Btw, this one also arrived, and only does 25 mW, so license free.
(I presume that the Eachines one also doesn't require a license when operating at 25 mW)
http://amzn.to/2nUheTd -- alternative camera

04-01-2017, 06:29 PM
Finally ready to screw on the top of the new body for the first time.
I moved the 'bot around a little bit, and there was this burned smell in the air ...

I had placed it on top of the LED indicator board for the scoring system.
The legs are metal, and thus conductive.
The indicator board burned out the trace from the power-in to the first transistor. I guess I'm lucky that this trace was so thin that it served as a fuse :-)
However, the scoring board now doesn't seem to want to send anything when I connect a scoring panel and bang it.
So ... maybe I ruined the scoring board? :-( I should probably

Also: I semi-religiously tape up boards with exposed backs with electrical tape to avoid this kind of problem. But not this board, this time. I guess it's time to get as much religion about this as I've gotten around "blue thread locker, every screw, every time!"

04-02-2017, 01:35 AM
I stand atop a mountain of Yaks, razor in hand!

But, as a side effect of making sure my scoring system integration is solid, the MWScoreArduino sketch is improved, and the MWScore Python GUI tool has some fixes, so I guess that's worth it.

All the bits that go under the hood seem to work now, so tomorrow I work on IK for the new legs!

04-02-2017, 04:40 AM
I guess I'm lucky that this trace was so thin that it served as a fuse :-)

Oh, dear!

04-02-2017, 01:00 PM
Want to try shaving this yak next?

04-02-2017, 07:25 PM
Silly Tician, cats are for herding!

Anyway, I got a video of turning it on with servos turned on for the first time, and it mostly worked! No exploding into a pile of burnt-out parts.

Also, it probably helps that I start up with max torque at 20% of max, and with initial very slow movement to a known-good position.
Because I had mounted one tarsal servo 180 degrees off :-)


04-04-2017, 11:53 AM
As you can probably see in the video, the tibias are too short for a good gait. Which means I have to shorten the femurs, or lengthen the tibias.

Yesterday after work, I dashed to the shop, and cut out four new tibias, about 40 mm longer, using the fastest (read: most ghetto) approach possible. No de-burring. No tabs or soft jaws. I even used extra-wide coupons to avoid having to worry about hitting the vise. I flipped it upside down and shaved off the back to separate it, which leads to a marred finish for the last inch or so (when only a thin sliver is holding on to it.) You can see the raw parts in this photo:


Helpfully calling out the terrible, terrible finish I get from my quick hacks.

The good news: Including putting on a vise without keys, two hours from start of setup to finish of cleanup.
I bonded some 1/2" steel balls to the ends using JB Weld overnight, so tonight I'll get back to doing IK with presumably better downreach.

Separately: Because of the way the aim yaw servo is mounted, I have to lift the top plate straight off, which means that as soon as the turret is mounted, I can't service the innards. This is sub-optimal during development, and maybe even during competition.

I'm considering cutting off the thin bit towards the front (right in the video) between the turret servo and the edge, so I can slide it off backwards if needed. There are still connectors that go through the cut-outs in the top, though, which may not have enough slack to let me slide it all the way out, so I'm not sure even that will help. Also, the turret may still block the screws that mount the plate to the servo.

We'll see!


04-07-2017, 12:25 AM
Almost complete turret upper half (without the yaw servo assembly) with camera, gun, magazine, and connectors.
It just needs the video transmitter, which I'll either stick on the back or perhaps right behind the magazine.


04-07-2017, 01:02 AM

Driven by a OpenCM 9.04 microcontroller. (The 3.3V out is actually enough to drive the servo movement without tanking the MCU.)

What do you think? Should I get a second camera on my 'mech?

04-07-2017, 12:22 PM
To aim upwards, I need to extend the regular U bracket (or, rather, the servo horn) so I get enough clearance in the back of the turret to point enough upwards to be able to hit one of those 36" tall bipeds that's sure to show up.

When extending the horn before mounting the U bracket, I also get enough space that I can add a better thrust bearing than the little Teflon washer that comes with the MX-64 horn normally. Thus, I got some 30x47x4 thrust bearings from VXB. (These are two circular washers, and one circular flat needle bearing to fit between.)

To do THAT, I need to make the bottom side (which mounts on the body of the 'bot) flat. Right now, there's the 2mm Delrin plate, with screw heads sticking up, mounting to the 3mm servo body flange setback. So, three surface levels: plate, servo body, and screw heads.
I had this same kind of thrust bearing setup for the AX-12 I used for steering each wheel on last year's Money Pit, so I'll make an aluminum shim that looks like this:


That gnarly pocket is the 1mm difference between the servo body face, and the Delrin plate. The circular holes are space for the screws that screw the plate into the servo. You're watching this shim from the bottom; the other side is the flat bit that the thrust washer pushes on.

Now for the obligatory whining, and request for suggestions from the machinist in the audience:

I spent probably an hour last night trying to convince Fusion 360 to cut along the edge of that pocket with a 1/8" end mill. But, because the holes are where they are, there's no uninterrupted edge for it to follow!
The best I could do is select the bottom of the pocket as "pocket," but because the holes are in the way, it doesn't go all the way to the edges, because it wants to stay inside the pocket:


The least-bad option I could find was using Contour on the top face, and make the bottom of the cut be in line with the actual pocket bottom:


I wish there was a way to tell it to include the known "open" areas in the "okay to go" plan for the pocket! Or use planar projections of features to add to the contour used for contour following. There's no guarantee that my (here) top face will have the path available that I want to clear, even though here, luckily, I did.

All in all, though, I'm still really impressed with Fusion. My daugher uses it to design brackets and then 3D print them; I do the same, plus designing parts and generating tool paths. It's quite pleasant, most of the time!
(Witness me spending an hour trying to figure out how to get it to do what I want, rather than just writing the G code myself ...)


Also, I'm doing this on tabs, because I'm making one of them and can't be bothered with anything fancier.

Tonight, it's just me, and the mill, making sweet, sweet chips!

04-07-2017, 01:09 PM
I've been wondering if it would make sense to have one person driving (using one camera), while another operated a stabilized turret with its own camera and laser pointer. I would think it would be hard for someone else to hit you if you kept moving, and easier for you to fire from a stabilized platform.

It's what the US Army does with its Abrams M1A2 tank, which also has a smooth-bore cannon. So we 're in good company!

04-07-2017, 01:19 PM
Strafe-circling robots certainly would be in the future. Maybe some bunny-jumping, too, if strong enough actuators can be found ;-)

If Josh shows up with Super Mega Microbot, he'll be a force to be reckoned with. It may be that I have no choice but to go stabilized-turret next year ... This year, I just want to field a robust, working robot!

04-09-2017, 12:04 AM
Trying to improve the communication between controller and bot.

Even though I only send a response right after receiving a packet, and set the packetization timeout to 1 blank character and the packet send size to 5 bytes (which is my frame size,) theS3 Xbee 900 MHz I'm using cannot turn around the air interface in 30 milliseconds.

Here's a picture of the send and response, top to bottom:
- Controller send
- Controller receive
- Robot send
- Robot receive

and then the same as analog.


There's a 100 ms blank around each time I send a response packet of a few bytes.

Also note that, even in the cases where I don't send a response packet, sometimes multiple command packets arrive at the same time on the robot. It's as if the Xbee waits to packetize the data even when it's supposed not to.

I was running OpenCM IDE on Windows, and the controller on Linux. Debugging using two keyboards/screens is annoying.
Thus, I tried the Robotis OpenCM IDE for Ubuntu 64-bit.
Unfortunately, the actual compiler toolchain the ship is 32-bit, and that's not supported by default anymore.
So, I tried pointing the IDE at the arm-none-eabi-g++ version 4.9 that comes with Ubuntu. I reverse engineered how the IDE uses the bundled toolchain to build the Arduino libraries and the sketch, and built a Makefile to do that.
However, now I get to the "how do I upload this program?" and I can't figure that out; despite verbose logging turned on, I can't tell what the IDE is doing (it doesn't print.)
I have dfu-util, but something else needs to be done to kick the board into DFU mode, or whatever else it's doing to upload.

So, I'm giving up on that.
I don't yet know whether I will use another Xbee for the reverse direction telemetry (THREE XBEES ON BOARD!!!) or stick with the 10-15 Hz control rate I can actually achieve right now.

04-09-2017, 01:25 AM

No DFU, just a very simple bootloader with AT command set.

04-09-2017, 01:48 AM
Oh, that's nice. Thanks!

Separately, even without any air turn-around, the 900 MHz Series 3 Xbees can't separate 5-byte packets sent with 33 ms interval.
I frequently get 2 of them mushed together after 66 ms instead.

I've set "packetization timeout" to 1 char time, and "packet size" to 5, and max packet size to 40, and "streaming limit" to 15. Maybe I should just reduce the streaming limit.

04-09-2017, 11:58 AM
Oh, I also set "retries" to 0, to make sure I'd rather lose a packet than stall the stream. Still, no 30 Hz stream of commands. A 15 Hz stream is alright, too, I guess. I should also try this with 2.4 GHz modules just to see the difference.

Separately, I got tician's uploader to work with my GCC 4.9 based makefile build of the OpenCM project, and it seems to be running (at least to the point where it detects that USB voltage is too low to run the servos and goes to a blinking warning light.) So far, so good!

I also cut larger side plates for the turret; it now fully protects the AEG mechanism, the laser, and the camera from the sides. I also got some 1/32" polycarbonate that I'll put across the front to protect the lens, although I think this lens is glass rather than acrylic and thus slightly more robust than the previous one that got busted by a BB.

I'll either have to make little brackets and print them, or I'll have to bend the polycarbonate reasonably accurately. The strip heater at Tech Shop is broken, so I'm thinking of other ways of accurately heating just the bend line ...

04-09-2017, 02:54 PM
When I use GCC 4.9, I lose the SerialUSB serial port functionality on the OpenCM 9.04, so I have to reset it with button held down and wait 10 seconds to drop into bootloader.
I'm likely losing the SerialUSB because some startup code something isn't being called right, or I'm linking the wrong binary-only startup vector library (there's a "medium" and a "dense" library, without corresponding .S or .c files)

The OpenCM worked great for the Mini Darwin, and worked OK for previous iterations of Onyx, but I think I'm done with it after this iteration.

04-09-2017, 04:28 PM
Come to think of it, Lexan bends cold, doesn't it? I just need to cut strips and finger break it. Easy Peasy!

04-09-2017, 06:21 PM
Come to think of it, Lexan bends cold, doesn't it? I just need to cut strips and finger break it. Easy Peasy!

Yeah, it bends really easily by hand, or with a set of pliers for increased accuracy. See Numa/TwitchMX ammo bins :D

04-09-2017, 11:19 PM
Pliers are good, too!

And I look forward to seeing those ammo bins in the coming weeks, as my robot masterpiece trounces everyone else! (Totally gonna happen with me not even able to practice driving yet; TOTALLY!!! :cool: )

04-10-2017, 08:15 PM
Hah! Testing?!? I'm way behind you.

04-10-2017, 08:55 PM
Carbon fiber looks cool, though!

04-10-2017, 10:35 PM

The skittish dog hates it, the old dog doesn't care.

04-11-2017, 08:49 PM
The gait engine is new (of course -- why re-use what works?)
The point here is to have four feet on the floor about 40% of the time, for presumably a more stable gait.
Seems to work alright.


Also, some home-built piezo target plates to match the official R-team ones.


I followed Josh's lead, and built these on an ATTiny85. It already has an analog comparator with interrupts built-in, so yay!
There are only a few additional parts: A couple of current limiting resistors, a potentiometer for sensitivity, a de-coupling capacitor, and a Zener to avoid too high input voltage.
There are red LEDs pushing through the front. Not as bright as the insane white ones on the R-team plates, though!
The piezo is mounted straight to the board, and then Shoe Goo bonded to the front plate. This seems to transmit the pellet bounces just fine.

Because there's a microcontroller involved, it can beep the piezo element on start-up and flash the LEDs as well to make sure it works.
Also, it generates a well-defined square wave of a few milliseconds on hit, and makes sure to then not generate the square wave for a few milliseconds so there's a clear and easy transition for the transponder board to detect.

The front plate is 1/32" Delrin; the back plate is 0.08" Delrin (because that's what I used for the main plates of the 'bot.) Laser-cut Delrin is my new favorite material; it cuts almost as easily as acrylic, and is much tougher.

Three flaws I've found in my own design:
- The Zener is straight across the Piezo element, capping its output voltage to 5.1 Volts. It should actually have been across the potentiometer output to the input detect pin. As it is, the range of sensitivity is from "very sensitive" to "fairly sensitive."
- The potentiometer allows me to short the detection input pin (which needs to go to 1.1V to detect a hit. This isn't so good for the beep-on-startup case, where it will make the MCU drive the pin into a short to ground. A more robust design would add a 1 kOhm resistor below the trim potentiometer.
- The Dynamixel-style connector has some leverage towards the mounting screws, so if I pull too hard, I may rip the detector off the front plate perhaps. The R-team panels have the connector smack between two screws, which is more robust.

Anyway, I highly recommend this ATTiny85 approach. Highly configurable, highly programmable, and probably eaiser/cheaper/more robust than a design based on a couple of op amps and a lot of passives.

Well, that was more about the scoring panels than about the walking. But I'm really excited about the walking! It's not even as smooth as it can be yet, because one out of fourteen iterations ends up timing out asking for the status of a turret servo that isn't yet mounted.

04-12-2017, 12:19 PM
I had a picture of the turret mounted, and approximately all the necessary bits and pieces in place (modulo a few screws, some solder, and some polycarbonate to protect things.)

Then I looked at it, and realized that no human being can actually tell anything from the picture; it's just too much of a mess of things, blending in with the workbench mess of things.

If you like playing Where is Waldo, here it is:


04-13-2017, 12:24 AM
Aiming for a fully assembled test tonight, the gun cycle sensor didn't work.
There are 45 bolts and 2 cables to remove to get at where it's connected.
While I have it apart, i should probably hit all connections with some glue (especially pin header ones)

Is shoe goo going to dissolve the nylon housings and vinyl sheaths, or do you think that will work O K?

04-13-2017, 06:26 AM
I would think it would be ok; and it would be quick work to test it. I use a daub of RTV myself.

04-13-2017, 11:34 AM
I dabbed some Shoe Goo on each of my connectors (except the Dynamixel SPOX connectors; those seem solid) this morning; we'll see tonight whether that was ill advised or not :)
Also, the goal for tonight is a qualifying video for both 'mechs. Obsidian (my daughter's mech) should be able to pass right now, although it doesn't yet have a good solution for scoring panels. Onyx X needs to be re-assembled and re-tested, but that "should only" take "an hour."

04-13-2017, 12:38 PM
shoegoo doesn't damage the connector plastic. It also can be picked off after It cures. Obsidian can borrow loaner target plates at Robogames for the matches. You can try out the mechanical interface for Obsidian with one of the plates you have now. If you are missing transponder cards or Xbee radios there will be some extras at Robogames that we will bring that you can borrow.

04-13-2017, 02:31 PM
Great news on the shoe goo!

Yes, we're planning on using the validated plates at the game; we're using the ones you sent for fit and some others I built for full integration testing.
I also already got a transponder of the new kinds, so I'm all set! (Well, apart from not having a 'bot that can make a qualification video yet ;-)

Obsidian's main problem is that it's based on the PhantomX Mk II quadruped, which doesn't have a convenient flat side to mount the panels against. She's trying different 3D printed parts to make a fit, without pushing them too far towards the legs such that the legs would bump into the plates. Although she already professed a love of duct tape, should all else fail ...

04-13-2017, 02:38 PM
Obsidian's main problem is that it's based on the PhantomX Mk II quadruped, which doesn't have a convenient flat side to mount the panels against. She's trying different 3D printed parts to make a fit, without pushing them too far towards the legs such that the legs would bump into the plates. Although she already professed a love of duct tape, should all else fail ...

Along with the team-built mech, I plan to bring a refitted phantomX mkII I used in 2013. Calling it Joshua. Still haven't worked out panel mounting. Curious to see what you two come up with. Actually, also curious how you are doing on servo load with that frame. I had to double up my knee servos to avoid overheating in 2013.

04-13-2017, 02:54 PM
also curious how you are doing on servo load with that frame

Yeah, there's a mod I did before and we're keeping. I don't have super great pictures of it, but perhaps this helps:


The idea is to have a "spool" screwed into the servo horn using the same screws as the brackets.
The "spool" acts as the pivot/center of some torsion springs.
There are then additional mount points for these torsion springs to push against on the brackets.

I made those parts in ... 2015? They seem to work alright, giving just enough push to not overheat the servos.
I actually have some slightly stronger torsion springs in the toolbox, too, should that be needed.
At that point, the servos are actually pushing the other way to get the robot to stand at rest :-)

The aluminum brackets used as the push point for these springs are the main clearance hazard we have for the scoring panels; there "should" be enough space to fit everything and walk without bumping our own panels. We'll also need to trim the legs of the torsion springs a bit; they poke out too much right now!

04-13-2017, 02:57 PM
The "spool" is actually two parts, the inner part has M2 mounting holes to screw it in and clearance for the screwdriver; the outer part is a "lid" that screws on to a threaded inner hole on the inner "spool." One of the first times I used designed-in threaded holes in anger on a precision part and lived to tell about it :-)

04-13-2017, 03:37 PM
The aluminum brackets used as the push point for these springs are the main clearance hazard we have for the scoring panels; there "should" be enough space to fit everything and walk without bumping our own panels. We'll also need to trim the legs of the torsion springs a bit; they poke out too much right now!

Thanks for the info. My clearance issues are even worse; I have a whole ax-12 in the same spot. I think I will have to put the panels above the chassis and have a comically tall turret.... again.

04-13-2017, 06:37 PM
Well, that's good for Onyx, because the current mounts for the panels makes aiming down hard. I get about 5 degrees of downwards angle. I'll just have to rely on being able to be far away at all times for people with low panels.

(Also, considering the melee lances SOME PEOPLE are planning, that might be a good plan in general.)

04-14-2017, 12:03 AM
Okay, everything tightened up again. I was all ready to set up for the qualification video, and then I realized I had forgotten to put in the code to actually move the turret in response to the aim commands :-) And then friend game night happened and I'll do qual tomorrow.

Separately, I like the attempt to keep four feet on the floor as much as possible. Each time it lifts a pair of feet, the video jerks a little bit, so I'm going to try to shorten the time in the air for the feet. I may also be able to shift the center of mass to balance a little better once everythings in its right place.

But, how much mass is really needed to make an effective gyro? I think it's more a quesiton of speed than sheer mass, right?
When walking, I have clearance under the robot, and I do have a "pancake" brushless motor and a 20A brushless ESC laying around.
I'll go research the math for gyros. I don't think I'll actually be able to swing it for this iteration, but it's certainly something to consider for next year! (That, and a stabilized gimbal for the turret)

04-14-2017, 12:20 AM
But, how much mass is really needed to make an effective gyro? I think it's more a quesiton of speed than sheer mass, right?
When walking, I have clearance under the robot, and I do have a "pancake" brushless motor and a 20A brushless ESC laying around.
I'll go research the math for gyros. I don't think I'll actually be able to swing it for this iteration, but it's certainly something to consider for next year! (That, and a stabilized gimbal for the turret)

That sounds like it would be some combination of mechanically questionable, computationally awful, and energetically impractical, so I look forward to you proving me wrong next year.

In all seriousness, interesting problem. You could mount it vertically and leave it constantly spinning, which would be energy intensive, and the torques from precession would be a wonderful pain in the ass to model. You could mount two perpendicular to each other and spool them up and down as reaction wheels, which may or may not be less energy intensive. Or some combination of those schemes. Any way you slice it, its going to be a bulky, maddeningly complicated power drain. Sounds fun.

Why not just pick a gait with 3 legs on the ground?

04-14-2017, 12:22 AM
Also, when I start turning, I may actually first turn in the opposite direction than intended.
The reason is interesting. (Well, to me :-)

I turn by applying an in-phase rotation of the desired IK end position, around the center of the robot body.
(This is different from just adding a hip servo rotation, because the hip servo is not at the center of the bot.)
However, to get a good gait, the "center" of normal forward/backward motion does not put the legs 45 degrees out, but more like 30 degrees out.
So, to take advantage of the full rotation angle possible, I make the rotation stroke extend in the whole 0 .. 90 degrees arc, which means it moves more "forward" than it moves "backward." If I didn't do this, I would get fewer radians per second of turning speed, AND I would hit the target plates between the legs because they would over-extend. (Let's say normal gait is between 5 degrees and 55 degrees of the hip servo, where 0 equals straight out.)
So, because certain turns rotates the legs such that the are maximally rotated at the pessimal phase, I have the options of either shortening the default stride, or reducing the turn speed, or both. Or I extend the rotation more forwards than backwards, using the full 90 degrees. In the above case, the maximal rotation command would result in an additional 35 degrees rotation forward, but only 5 degrees rotation backward, with the 15 degrees offset (center) of that extra rotation added to the hip servo.

When I fade in the rotation motion, that actuall may make the leg rotate "the wrong way" for a little bit, because of this offset from center. That is what causes the rotation to start out going in the wrong direction.

There may be something smarter I can do, other than just shortening the strides (which reduces performance of the 'bot.)
For example, I might be able to only change the amount of rotation applied while a leg is in the air. Because my step rate is about one step every 0.7 seconds, this would add some more latency to the control. I already have to live with 100 ms latency of the Xbee commands because that's how the 900 MHz modules perform.
(You may recall I ended up using ESP8266 WiFi modules with UDP networking before, because they were actually much faster, as long as a working 2.4 GHz spectrum is available ...)

04-14-2017, 12:25 AM
Also, situational awareness of quadruped legs around chairs and table legs is hard.
Here's hoping the buildings stay in place when bumped in the arena :-)

04-15-2017, 12:07 AM
Did you know that /usr/bin/sendmail moved to /usr/sbin/sendmail somewhere between Ubuntu Precise and Ubuntu Trusty?
Well, neither did I, until I had to spend the evening debugging why emails suddenly aren't sending from some systems, rather than making a robot video.
Oh, and Amazon/UPS re-scheduled the package containing the case I'll put my remote control station in, because weather in NY. Instead of arriving today, like I paid extra for, they claim I might conceivably still get it before the Robogames starts. Who needs time to build, anyway?

04-15-2017, 06:54 PM
So, the unopened bag of 5000 BBs I had in the box turns out to have bio-degraded all by itself in the bag. They're covered in sticky goo and smell of vinegar. It's about 1.5 years old, so I guess the freshness time on those is just a few months.

I have a couple of BBs that have been out in fresh air, still biodegradable, but they seem to be in better shape. There's like 20 of them in a little tin on my desk -- probably enough to calibrate and do the qualification video (although I'll probably take y'all up on the offer to extend the qualifying video deadline!)
Wal Mart doesn't carry airsoft in its NorCal stores, and the earliest Amazon can get new BBs here is Tuesday.

Also, two nights ago, I focused my aiming laser to a nice dot at 10 feet, and hit the lens/focus insert with super glue. Today, it's totally out of focus, and it refuses to be re-focused, because super glue. Comedy of errors!

Luckily, I have two spare red laser modules. Now I just need to disassemble the entire turret (again) to get to the point where I can swap out the laser.

In other news, the graphics for the control station is coming along fine. Because software is easy :-)


Yes, I'm well aware that saying "software is easy" will cause Murphy to ensure I lose to some software glitch. Bring it on!

04-19-2017, 09:37 PM
I've been building again! The case arrived, and I laser cut a plywood insert that I screwed a bunch of control-a-tronics into.
It runs on mains or battery power; easy to transport and charge; under-voltage lock-out; 4A fuse on the battery (well, 4A hold, 8A trip, anything in between is debatable, because it's a polyfuse.)

Raspberry Pi running the GUI; 5" 800x480 display using an Adafruit Kippah to reduce display bulk (this works out great!); XBee, 5. 8GHz 10" diversity receiver display; power control / battery protector board (re-purposed from my walnut/brass control panel two years ago; ATTiny85 based); voltage regulator and display for the Pi; Xbox controller; mini wireless keyboard; wired Ethernet extension/breakout.

The case (yellow plastic) came with five crossed protruding 10 mm in the lid; perfect for mounting things. I tried drilling/threading the plastic, but it's polypropylene, which is tough but soft, so that didn't work out. Instead, I got some blade-time M3 brass inserts (intended for wood) and screwed them in; that seems to work much better.
Also, everything connects to ground, and many things connect to each of the three power rails (battery/power adapter; 12V on/off/protected; 5V regulated.) I didn't want to solder everything to everything, because that will be a pain to service, so this is my first build using power rails! I got some ground bar at the Home Depot to screw everything into; it's designed for 14 gauge and thicker wires; I'm running 16 gauge, but the bar works fine for this application; connections seem tight enough. 16 gauge is as thick I want to go for these 1-2A curcuits; even that size is hard to jam into some of the receptacles it needs to go so I splice finer gauge for the final bit for a few things.

Also, I got more BBs, because the old ones had decomposed (did I post about that already?)

Also, the quality of the 900 MHz Xbee is going down. Used to be, I'd get 120 ms round-trip times, but now it's up to a second. Maybe some neighbor is talking on the phone or something ...
I may want to also bring a pair of 2.4 GHz ones, and see which ones work better at the actual games.

04-20-2017, 08:16 PM
Okay, so it all works okay now. I put some thin Lexan in front of the camera, and the metal focus ring in front of the laser, and the rest of the bot has hard surfaces, target panels, and heat sinks facing outwards. The one other thing I'm not sure about is the antenna for the video TX. I'll bring spares.

The control center came out pretty well. I wanted to let the undervoltage board report the power voltage to the Raspberry Pi for display on the control screen ("POWER LOW!") and similarly let the Raspberry Pi tell the undervoltage board when it's time to turn off the power (after a shutdown,) but I think there are some bugs in the Raspberry Pi wiringPi libraries and/or GPIO utility that make it not quite possible to use the GPIOs available after the Kippah steals 95% of them in the way I want. It's not that important, and I ran out of patience to debug more. One constraint I put on myself was that I don't want to suid the control center to root, so I have to use the GPIO sysfs interface, and use the gpio tool to export GPIOs beforehand. But, as I said, I'm pretty sure it has some bug related to the difference between BCM numbering and WPI numbering, both of which are used in the API in different places. Maybe if there's downtime and no emergency repairs needed, I can noodle with it at the games.

Aaaanyway, I'm pretty happy how it all turned out.



04-20-2017, 08:19 PM
BYI: regarding gyroscopes, keeping them spinning once they're at rate will take very little current! Think of the balancing gyroscope tchotchke you can buy in gift shops, that balance on a pencil tip and is started by a simple string pull. I think they can go for quite a while, as long as the bearings are good!

Regarding the computation, I'd probably rather just engineer it, by adding a 6DOF MEMS sensor and simply counter-act the forces that are actually measured on the 'bot. After all, it's remote control, not autonomous, so I don't need any kind of precise odometry.

04-24-2017, 07:20 PM
Onyx did great! I got out-maneuvered by the first place champion, which shows that I was right in fearing the well practices skills of the R-Team folks :-)

There was one sad failure where Onyx just shut down, and my best analysis says they hit my "safety" rocker switch enough to temporarily clear it. Unfortunately, once off, the bot needs a positive action to turn on again ("start button") and thus I was left without power. I slathered the switch in electrical tape for now, and will update this part of the design. I think I'll just go for a planar pushbutton to turn off, and not keep the "safety" rocker. Maybe also hide the off button further inside the bot. (But it's useful to have a quick off option when testing/developing!)

All in all, very happy with how it went. Mid-event, I gave up on good engineering practice, and hot glued a small 170 degree FOV camera-transmitter ("tinywhoop" style) combo, and that turns out to be a great upgrade. I'd use the wide FOV for walking, and the 60 degree FOV security camera that's my main camera for aiming. And this means I used two receivers, too. Turns out, I wasn't alone in this; Jim/Nomad had already had this idea, and had integrated it in the very slick control center he uses.

Speaking of aiming, I taped over the laser after a while, because using optical aiming on the screen was reliable enough, and the laser would give me away when I walk around. ("Oh! A red dot? I bet he's coming down that lane!")