Archive for October, 2012

 

Hurricane Robot Videos

Oct 30, 2012 in CRJ Wallbanger, Null Hypothesis, Project Build Reports, Stuff, Überclocker Remix

Due to the sheer amount of ass-weather that is currently hovering the Northeast, I’ve taken the off-day to actually edit all of my Robot Battles 2012 video! Enjoy the following compilations of Null Hypothesis, Überclocker, and the Carly Rae Jepsen Wallbanger.

 

 

Little video snippers from Mike Jeffries, Dale, and Xo were used for some parts where my video was incomplete.

The First Testing Results of RageBridge(Two!)

Oct 25, 2012 in Motor Controllers, Project Build Reports

Barely a week after I first put out the call for RageBridge testers, I’m stoked to say that I’ve gotten the first usage reports back! Two of my boards were in use at the Combots Cup this past weekend, one in a 60lb bot and one in a 120lb class bot. Here’s what went down:

AWESOME! The board worked flawlessly until it caught on fire.

That’s actually what I want to see, because this establishes a good upper bound on what the board should be used for, as well as how it should be mounted.

The two robots used similarly powered motors in their drivetrains, but one was very weapon-centric and the other (which suffered the explosion) very pushing and drivetrain-centric. I’m told by attendees that after 2 minutes of a hard pushing match, the RageBridge board gave out. The other board seemed to have survived fine, given that in its application it was most likely not hitting the current limit as often due to the robot’s primary goal of chasing after an opponent with its whacky bar thing.

The thermal situation in the pushybot was also a little suboptimal:

Above is the robot, Ziege, a 120lb middleweight powered by 4 EV Warrior motors (admittedly a little power-starved on 60A). The black blob of tape between the two rear motors? Ragebridge. Talk about good ventilation! Basically what I’ve concluded right now, after only 1 data point, is that perhaps without additional cooling/heat sinking, it’s not a good idea to use RB in a 120lb battlebot. This is more informative than the statement’s facetiousness may indicate.

First, all ESC ratings lie to you.

Second, it’s been known to me that RB’s “40A” rating was a little optimistic. It was calculated assuming a constant current causing a certain amount of Joule loss (I²R) in the FET, and using the datasheet’s quoted temperature rise per watt of dissipation (Kelvins/Watt) to estimate a temperature rise from 25C ambient. Basically, for the FETS I used (the IRFS3004), this worked out to be around 76C for a final temperature of 100C. I picked that as the target temperature because most big electrolytic capacitors are rated to 105C. However, that does not include any additional sources of heat. In fact, the capacitor itself is a nice source of watts that is located very close to the FETs, hence contributing to their heating. The board traces, being relatively thin copper, will also contribute some resistive heating.

Interested in just how many “true continuous” amps Ragebridge could push with no help (e.g. fans, heat sinks), I set up a test rig over the weekend which was basically the board puking into a huge RL load while suspended in midair:

The “Big RL Load” in question is Cap Kart’s motor, a separately excited giant-ass DC motor. To get the duty cycle of the controller’s outputs to a reasonable range, a very small amount of field current was injected such that the rotor could barely overcome friction and spin up to a tame speed,  hence generating enough back-EMF to force the controller to work at around 50% duty cycle for the current I wanted to test. To maintain that current, I just set the Semi-Intelligent Current Limiter to the value desired.

The reason this was done was because different duty cycles load different controller parts preferentially. If I had just dumped into the big rotor windings at stall (which I tried), the controller would be running at like 5% duty cycle the whole time. That would have been all the voltage needed to hold 30 amps into the ~30 milliohm rotor winding (at the 20 volt test voltage). Very high and very low duty cycles preferentially stress one FET because it is either supplying all the current or having to freewheel all the current and is kind of unrealistic unless you know for a fact that people are gonna be running such low or high duty cycles all the time.

50% duty cycle is a nice worst-case scenario. While heating would be distributed evenly across both FETs of the conducting H-bridge half, 50% duty cycle really kills the capacitor (Here’s a good application note kind of thing with good buck converter design equations).

Every once in a while, temperature readings were taken of the region between the high-side FETs and the capacitor. This would be the single hottest part of the board, and hot it did get.

I became concerned about how fast the cap was approaching 100+ celsius after the first test. To mitigate this, I temporarily doubled the capacitance. Kind of cheating, I know, but I was also interested in seeing what the FETs were capable of. The first test was on just 20 amps, and the FETs had barely crested 50 Celsius when I called it off. They have quite a long way to go, but the capacitor was probably about to detonate.

Finally, after the extra 680uF of capacitor was added, the test was repeated at 30 amps:

SCIENCE. SO MUCH SCIENCE.

The “data” was recorded with a video camera and the data points gathered by watching the video and picking the temperatures that looked like of good. So, not exactly rigorous science, but it gets the point across. With no additional heat sinking, fans, airflow, or other cooling assist, the RB board sort of levels off at around 100-105 celsius after about 5 minutes.

Thermal equilibrium is really what determines what a controller’s “continuous” rating is. RageBridge is a “30 amp” controller at heart.

The only way to raise this current ceiling is by active cooling of the board. There is very little amount of practical heatsinking that can be done to raise the steady-state current. A well-designed and many-finned heat sink is more effective on its own because the increased surface area encourages more natural convection anyway, but a plain heat plate wouldn’t increase the surface area much. Hence, it would only prolong the time until the temperature limit is reached.

The world of ESC ratings is a perilous one. If I really sold Ragebridge right now as a “30 amp” controller, nobody would buy it. The reason is that the majority of robotics and traction duties aren’t truly continuous. A typical robot will accelerate in under a second, drawing full current, then cruise at a much lower current. Vehicles may hold that acceleration current for longer periods of time by virtue of being heavier and not being geared to safely spin the whels at a  low motor current. Unless you’re trying to drive motors that are way larger and more power-hungry  than needed for the application, the average current will be far lower than the peaks.

This is why “one number” ratings, like “40A continuous”, are useless without considering the circumstances of the test. Some ways to get around this rating are citing a number as “continuous” for some number of minutes. A typical “robot duty” might be 3 or 5 minutes. In this case, I think RB2 is a good 40A “3 minute” controller.  A truly 40A continuous ESC needs to have enough thermal dissipation ability to safely dump several watts of heat in the best case. It’s probably going to have a rather large heat sink or at least a fan, or be very ridiculously low resistance , which some R/C type ESCs acheieve by being very low voltage and using many small FETs in parallel to reduce resistance even further. For R/C controllers in particular, some amount of airflow is implied, usually prop wash from a plane.

Peak ratings can be even more bogus. It’s generally not disclosed how the test was performed – for the typical R/C ESC, it’s usually “Rated battery voltage” / “Rds-on of the FETs divided by number of FETs”, resulting in hilarious ratings of 1000+ amps from a ESC with 14 gauge wires. Without a method of test – like “100 amps for 10 seconds before reaching 150 degrees Celsius” it’s impossible to really tell what the “peak rating” is. However, for RB2, it’s dead simple – it’s whatever I set the hysteresis limit to!

With this test rig pretty well practiced and easy to set up, I might go ahead and try some other well-known robot ESCs to determine what their real ratings are.

For RB, though, I intend to generate several of these graphs and make them public & part of the eventual user manual. Maybe 2 different currents under 4 different cooling conditions (no cooling, with a heat sink plate, with a fan but no heat sink, with both). It would look much like the average IC or semiconductor datasheet, and it would be kind of easy to extrapolate what a safe amperage is for the custom application based on those graphs. I’d still have to cite a “one number” specification for the eventual brochure or specs box, though, but at least with Real Dataz behind it, I don’t feel as bad fibbing a little.

With 30 amps under the belt, I decided to try adding a little bit of forced convection. Here’ a quick fan mount I whipped up for the board that uses the existing standoff/mounting holes and a very small 12v, 0.12A 40mm fan.

The CFMs from this thing are rather low – about 10CFM rated, but it’s split fairly evenly in 3 directions (the 4th is blocked by a flap of the mount I made), so each side really gets about 3CFM.

This was also a chance to test out my new load. This is a 0.6 ohm, 550 watt power resistor. Conveniently, it’s not wound to cancel its own inductance, so it’s a nice…..little?…. RL load.

With the resistance being fractional ohms, it’s easy to push tons of current through this thing. I also have a known fixed relationship between current and voltage, so if I wanted to achieve the ideal 50% duty cycle for stress-testing the board, then I can set the power supply accordingly. For instance, if I wanted 50% duty cycle at 30 amps, I would have set the power supply to 36 volts (30 amps * 0.6 ohms = 18v output at the controller, and 50% duty cycle represeting 18 volts average means 36v input).

Unfortunately, the board has seemingly started exhibiting regulator resetting issues again. It usually occurs a few minutes into testing the current limit, and the failure is “soft” i.e. the gate drives just shut off due to low voltage. The regulator once again enters a weird latched up state that I supposedly solved on RageBridge1 a few months ago. This time, I’ll need to hunt down the error a little more carefully. It could have been that, for example, a solder joint was stressed during the last test’s heating and cooling cycles, or some other equally hard-to-find bug.

Before the board reset, though, I was able to get the temperature to hold approximately steady at 58 to 60 celsius after about 4 minutes. This is a good sign that I can (after I figure out that damned regulator issue) start upping the amps to find the limit of what airflow can do!

In the time I’ve been waiting to hear back from users, I’ve made a few changes to the board to resolve some of my (and others’) complaints and some of the issues exposed in this thermal testing:

ragebridgetwo v2

RB2′s first version had a few issues which were typical of me rushing a board out the door.

  • There was a single digital pin input to enable the Mix mode, but it had no corresponding ground or 5v jumper to attach to! Not sure what I was thinking there – to active mixing I had to solder a jumper wire (and tell other people to do so).
  • The one capacitor is clearly not enough, and some rearranging of things is needed in order to fit one more per side.
  • The gate drive regulator only takes approximately 15 volts input. I think it should have the ability to run off a 12 volt battery, because 12v systems are still extremely common in small robots as well as in FIRST Robotics. I’m not discounting the possibility of eventually going after FIRST with this thing, but having a controller which has a very wide voltage input is just nice.

The latter problem took a while to think about and fix. There are very few commercial regulators which can stand the whole range of voltages I wanted – down to 7 or 8 volts (for the really, really flat 12v battery) and up to 55-60v for a 36v nominal system which can see some spikes and surges. The standard solution for me is to buck-regulate (down-convert) to the gate drive voltage (12-15v) and then linear regulate to logic levels (5V). However, this means pretty much the lowest voltage that RB can operate at – period – is about 12-13 volts. The buck regulator, a LM2594, just switches full-on during this condition, but it has a 1.1v drop from input to output. Add in another drop of the output diode of approximately 0.75v and I am wandering dangerously close to the 10v shutdown point of the IR21844 gate drivers. That means RB technically can’t run off anything lower than 4S lithium polymers (14.8v) safely, hence cutting off the “12v lead acid” market.

A more robust method is to buck down to 5 volts first, and then boost from 5v to the gate drive voltage. Many super LV-input controllers either do this or the janky thing of just running the gate drive on 5-7 volts. The downside is that it requires 2 converter chips – a high voltage input buck regulator and then a little boost. Neither are that cheap, especially HV input regulators. But, this method allows operation almost right down to 5 or 6 volts!

Wouldn’t it be nice if they made something which could either buck or boost and take the entire target voltage input range? It turns out (after hours of rummaging on Digi-key) that such devices do exist.

One example is the LT3971, a buck-or-boost converter designed for LED power supplies. It takes 4 to 60v input and gives you whatever voltage out that you select. I was really favoring this until I realized it doesn’t have internal switches – i.e. integrated FETs. I was going to have to build a motor controller on top of my motor controller (sup dawg) with tiny FETs in order to use it! This is basically a project entirely on its own.

Then I found the LT3433, which is a much simpler device with internal switches and needing just an inductor and a handful of passives. It could theoretically accommodate 4-60v also, but presumably due to the compromises of its design compared to the more freelance 3971, it really can only work down to about 8 volts in my application. Whatever, close enough. It was also kinda okay priced in large quantity – only $3.40 in 100 or more on Digikey. I’m certainly getting gouged for buying one or two for testing (what do you mean it costs 6 dollars)…

Doing the layout for this thing was an adventure. First, it needs so many passives. It has all kinds of fancy compensators and buttons and switches. Second, I use 1206 parts.

Stop laughing. I know it isn’t 1982.

I’m invested pretty heavily in 1206 parts, though, and find them convenient to work with because they are still quite large. Really I should be working in 0603s – about the biggest thing you find in modern electronics.

Here’s the first picture of RB2V2:

Doubled caps, check. Actually useful MIX enable header, check. The main power inputs had to move, so I’ll have to rebuild my test jig, but that’s a small potato.

I also added an external LED header. One of the ways people apparently mount these things is heat-shrinking the entire thing and gluing it to the robot. I’m mildly peeved, but even they deserve blinking lights, okay? The header is pretty much a tap from the LED circuit, so there’s no resistor required.

The LT3433 and its passives have not been routed yet. It took a few rounds of arranging before I settled on something which wasn’t utterly terrible.

Here’s the final routed layout of the new power regulator. I’m sure I could have placed some things more scrupulously. What I learned here is that I hate TSSOP packages. You can’t even thread a trace through their pins because they’re so damn close together. This also isn’t a 4 layer board, so it’s not like I can just escape onto another layer. That thermal pad in the middle is really, really in the way of everything.

There’s some parts of this board which I have doubts can actually handle the output of this chip (400mA-ish maximum), but I’m hopefully never going to run that level of current on the gate drive rail unless someone’s powering lights off the fan header or something.

I’ll let this design “bake” for a while, stare at it again, and send it off for fabrication. There will not be another alpha testing round, however. I’m going to get maybe 4 of these maximum and beat them up in various ways. The power lay out and most components are totally unchanged from the current testing round. If these boards prove to be legit, then I plan on launching a production run ASAP.

 

 

The RageBridge Breeding Program: Alpha Tester Application & Other Stuff

Oct 14, 2012 in Motor Controllers

They’re done!

After my Digikey and Avnet shipments arrived, I could finally finish out the 8 remaining RageBridge2 boards in the panel. Using my handy dandy hot-swap test rig, I’ve determined that they at least power on right now without exploding, which is a good start.

Before I upload running code, I’m planning on adding a mix option to the firmware which can be activated by soldering a little jumper wire (a future board rev will add a header that can be used to select it). This way, the controller can be used with non-mixing radios (like 2 channel pistol grips) to let one channel control steering (differential) and the other speed (magnitude).

Update 16 October! The mixing firmware has been implemented.

The two RageBridge2 boards I assembled last time have been tested in real-life driving already. First, I installed it in Null Hypothesis in place of the RageBridge v1:

Then I gave board serial #2 to Adam and had him install it in his pre-Dragon*Con speedballed robot Blitz.

And then, we faced off at the Somerville mini Maker Faire:

Basically what it reduces to is two somewhat gimpy bots driven by two out-of-practice drivers. The motor that smoked in Blitz was on the front lifting tines, and it was being driven by a Victor 883.

But despite my best efforts to test these boards out in a strenuous condition, Blitz and NH are kind of… the same. They both run 4 overvolted drill motors (and keep breaking them… clearly these things have gone totally to shit) coupled to 4 inch wheels, and while NH has a higher top speed due to my more overvolting, the RageBridge boards limit the  motor current such that the motors kind of behave the same anyway.

I need more data points before declaring the RageBridge Certified Legit™. That is why I will now officially announce the….

ragebridge breeding program

These 8 boards will be released “into the wild” as much as possible such that I am not in control of their use and installation save for a short user manual page. I’m therefore going to put the call out for participants.

You may qualify for the RageBridge Breeding Program if…

  • You have a load, such as a robot, vehicle, grain thresher, etc. which runs between 18 and 36 volts, has 2 DC motors, and would like about 40-50A, but can live with 60 amps at most. This is because the RageBridge has intelligent constant-current limiting set to 60A. So if you don’t mind a little… anemic acceleration on your twin Magmotor mountainboard, that will work just fine. At this time, the 2 output channels cannot be combined into a single high-current channel.  The 36 and 24v boards are currently not the same in order to test out different components, but the production version will run the whole range of voltages.
  • It exists right now and you can swap RageBridge into it. Sorry, projects which will be finished Real Soon Now cannot qualify.
  • It uses an R/C radio as an interface. RB currently cannot take analog inputs (e.g. throttle pedals) or TTL serial commands. “Vehicle firmware” which does take these inputs is one of the things I intend to work on as soon as possible, and serial commands is also on the list of things to add. The firmware is easily flashable in the field for when that happens; you will need an FTDI cable. After all, I do write the firmware for this controller in Arduino…
  • You are willing to send $50 USD to help me offset the cost of boards and parts. If it works great for you, then awesome – 36V dual motor controller for $50, and I’m not gonna ask for it back! But…
  • You understand that you are not receiving a finished product and there is no warranty on functionality or reliability. Do not use this to hoist people up elevator shafts or to run your heart-lung machine, for instance. Would you even use an Arduino to run a critical medical device like that?! Each RB board will be tested before it ships out and I can only take “returns” for DOA.
  • You are willing to send me video, pictures, and/or test data showing the board working in your environment.

If you agree with the conditions, send me an email (charlesg@ this 3-lettered university name .edu) with the subject “RAAAGE” (that’s 3 A’s) and the following information:

  • Your load details – what it is, and what voltage it runs, so I know which board type to send you.
  • How soon you intend to install and test the RB board
  • How you intend to mount the board in your load (via its mounting screw, heat shrunk, above a fan, on a boat with a goat, etc.)

Because there are only 8 boards available, I clearly cannot take everyone. I’m seeking “diversity of loads” here – vehicles, robots, elaborate dentistry tools, etc. I will set a deadline for “applications” of MIDNIGHT on Wednesday, October 17th (that means as soon as the clock turns to 12:00 and it becomes the 17th). Eastern Standard Time. I’ll notify both accepted and rejected parties then. They’ll ship during the week.

Preliminary specifications:

  • 18 to 36v nominal operation
    • Absolute maximum voltage for “24v” boards is 37v, absolute maximum voltage for “36v” boards is 57v.
  • 40A continuous at room temperature with no additional convection or insulation.
  • Constant-current region above 60A (your load will see a maximum of 60A, plus or minus a bit of ripple).
  • R/C servo pulsewidth range of 1900us to 1100us with 1500us center. +/- 20us deadband.
  • 5V power available for receivers
  • 4.5″ x 2″ outer footprint
  • 1.7″ x 1.7″ hole pattern for mounting, sized for #4 screws.

the ragebridge fundraising program

I intend to send out one more board revision before releasing the design to manufacturing. This new revision will wrap up some of the hardware loose ends like component placement, manufacturability, trace routing optimizations, and like, making the RESET button actually reachable with an average finger.

Boards and parts (especially parts for 10…) are still really expensive, especially in low test quantities where I can’t take advantage of price breaks.

If you like the RageBridge and its new addition of a constant current output mode to the small- and medium sized robot/vehicle controller world, and want to support its development, then please let me direct you to my donations page. There is no suggested donation, and contributing does not constitute a pre-order for any product!

The whole mission of the RageBridge project is to try and make a compact, reliable dual channel high-powered motor driver using 21st century designs and parts, with no “fanciness” like dual encoder inputs, built-in PID controls, 8 different ways of taking commands, etc. in one unit. It is a rebellion against the new trend in robot controllers to integrate all of these functions and charge more money for it while not really being that good at, you know, driving motors. Basically, I want to give the venerable Vantec series and Victor 88x series of controllers a this-decade equivalent. Raw, simple power for applications which demand it, and nothing more.

the ragebridge kickstarter

Support us on Kickstarter! The link to RageBridge’s campaign is…

Not yet. I fully intend to pitch this sucker up on Kickstarter when I have a demonstrably working device. No promises and renderings here – I’m fully intending to use KS to gauge the initial market and to tell me how many times to hit the button. So if you’re just totally into a public fundraising campaign or find paypal links repulsive, hang tight!

Some more 3D printing shenanigans: The Up!

Oct 11, 2012 in Make-a-Bot, Reference Posts, Stuff

Scheduled plug: I’ve added a pile of new things to the Stuff for Sale page! Go check it out.

An exciting new thing came for me in the mail right after Maker Faire, and I think I’ve gotten finished playing with it enough to post.

Back in June, I wrote up the Democratic People’s Republic of Chibikart for Instructables and entered the Make It Real contest. It won one of the first prizes, which is an Up! Plus 3d printer, to add to my flock of 3D printers.

That was in July. I just got it a week ago, due to Instructable’s famed lack of shipping organization. That said, I was greeted with this in the shop last week:

Shiny. Let’s open it up!

I see the thing…

Very shiny (looks like glossy enamel) indeed. And orange, I guess because this was an Instructables-commissioned machine.

The Up is a pretty simple machine. It uses the ‘overhung arm’ architecture where the table is mounted on one moving axis and the head is mounted on another traveling, perpendicular axis. Now, I actually think this is the worst design for 3D printers because not only do you have issues stemming from workpiece acceleration (it’s moving), but the axis inertias are also mismatched.

Furthermore, the arm that sticks out is really flexible – it seems to be only mounted by one flap of sheet metal. It The X movement of the extruder is transmitted as vibration into the arm, and the end can resonate a fair amount – at least 3 or 4 mm of wobble at the end! Luckily the printing occurs very close to the arm’s support, so it seems to retain resolution accuracy. But still, it makes the machine design side of me cry a little. The new Up! Mini addresses this with a dual-rail axis design.

It also has a really really loud buzzer that makes it sound like an overly enthusiastic microwave oven whenever it starts, warms up, and begins/ends a print.

It also comes with a fairly extensive toolkit. Fairly typical 3d printer diddling tools like tweezers and a paint scraper are included, as are build platforms, mounting screws, and a nozzle wrench (but no replacement nozzle). I also got a pair of fabulously pink work gloves, but I’m not sure how they’re supposed to be used (are you supposed to grab the nozzle while hot?)

After I made a klein bottle as the printer’s first test, I let it run overnight on this compound of 5 cubes.

I’ll take a moment mention the UP! software. As far as I can tell, it’s closed source. It offers the usual array of tunable features – layer thickness, speed (just fast, medium, or fine), and infill (loose, dense, solid, hollow…), but only generates a square mesh (while Replicator can generate hexagonal meshes or just line scribble). It also slices way faster than ReplicatorG, but the user interface is a little strange with its button press sequence to do a common task like scaling or rotating, but that is a minor complaint.

What is REALLY nice about it, though, is how it generates the support lattice. This is the one place where I think it beats everything for intelligence, because alot of planning has to go into making a homogenous-material (i.e. not dissolvable or something) support that just falls away when done. If you’re a Stratasys printer, you can just puke support material everywhere because the intention is for said support to be dissolved away in the bubbling cauldron of lye. This is a very different, controlled kind of puking.

That entire cocoon for my cube thing came off in one piece, with absolutely no knifing or prying. Same deal with the “raft” layer. Contrast this with the amount of scraping and filing I have to do to the average Replicator(G) print and it seemed almost magical. I’m not sure how it is able to do this -it doesn’t seem to pause for a temperature change when moving between supports and part, so I think it must just be very careful extruder control to make sure the parts just barely come into contact.

It generates several different types of support – there’s the loose lattice that is used to build up the bulk of the support, then a very fine and nearly solid layer that is the one which makes contact with the part (which makes the near trivial breakaway even more amazing). There’s also a “cross hatch” like option which is used only for the loose layers.

Either way, seriously, what? I wouldn’t mind seeing a more robust support generation scheme for Replicator. Or, even better, maybe I should try hybridizing this guy with our Replicator 1 and make an Uplicator. I’d love to combine the high speed-capable gantry head of the Replicator with the Up’s slicing engine and controls.

There’s also one more thing I like, which isn’t Up-specific but I have not seen it until now: perfboard build plate. I am a definite fan of this. On that giant 4.25″ wide print, there was less than 1mm of lift on one corner of the hexagonal base. In ABS! As far as I can tell, the little holes in the perfboard cause the molten ABS to flow into them and hence achieve a mechanical interlock, way better than counting on the strong force interaction or something with a smooth tape. The Up came with 3 pieces of 2mm-space perfboard. I’m tempted to go buy a 6 x 8 panel from Radioshack and check out how it works with our Replicator.

I did a little more research into it and found that perfboard is now a common build surface, especially in conjunction with “ABS juice” that is made of ABS bits dissolved in acetone and painted on the platform.

The more you know…

After experimenting with the Up, I was determined to tune our Replicator to achieve similar qualities. Most of all, I was out to play with the support generation to see if I can achieve a less tenaciously integrated support lattice. I had been opposed to messing with before since technically it’s not “my” Replicator, but belongs to our research group, but I have literally not seen anyone else use it except me, so who’s gonna complain!?

I began by turning down the support flow rate ratio in Skeinforge way down. I had noticed before that the support material was almost as thick as my part lines, which seemed unnecessary. Next, I increased the density of the interface layers (which seems to drive the density of the support layers) so there was more ‘support resolution’. This did involve figuring out a better system so I could get the raft off the part easier (the denser interface layers appeared to want to stick to the part more than anything else). One more parameter I messed with was turning up the “support gap” ratio, which caused the lattice to be spaced further away – this was increased from its native 0.005 (meaning pretty much touching) to as far as 0.1.

I tested these settings by printing a few overhang dongles using full support and rafts, then when I thought I was at a good location, by test printing a difficult object which required full supports: this figurine on Thingiverse.

I think it turned out pretty damn great. Full disclosure: I tried this on the Up! and it got about 3/4 of the way up before the wiggling of the build plate caused the nozzle to bump the whole print off the machine. Oops. That’s what you get for being non-gantry, I guess.

Chunking off the support was pretty easy, but there were definitely lots of areas where I had to knife pretty hard. It looks like I’m the first person on Thingiverse to even try this print, too.

Additionally, one thing I noticed was that the long runs of very thin support lattice (seen in the first picture of the print) tended to warp and buckle much easier than a thin walled part would, probably because the flow rate is modified so much. On smaller prints it was okay, but I’ve definitely had support detatch from itself and curl up before. Once that happens (it seemed to happen at the base of the model), it is generally very hard for it to pick itself up again.

So I decided to try turning on the “crosshatch” option, which normally in RepG makes a pretty damn solid lattice that is utterly impossible to do anything with, but turning the flow rate down even further. The result is what I will call “point cloud” support. The string of plastic breaks between intersections (or leaves very very fine threads) and basically forms a coarse-, open cell, layer-by-layer deposited foam:

 

The “point cloud” is supported by the interaction of all those fine drool threads  and is remarkably solid if you push on it, but it falls away in huge chunks and the remainder is easier to scrape off. Still not Up! class, but a pretty awesome departure away from having to chisel your part out of its own pupa.

 

I next tried this method on the ultimate test: something I 3d scanned, so is not going to be remotely clean or easy anywhere.

 

The model in question is a Hatsune Miku mini-Nendoroid figure that I own. Now, if you know me, you know that just about the only thing I can be considered a ‘fan’ of is Miku and the Vocaloid media franchise and user community. It’s difficult to explain what it is without sounding like an internet startup guy, hipster and open-source advocate at the same time. In short it’s crowdsourced user-supported synthesized music you’ve never heard of.

Hey, when did I get a 3D scanner?!

It’s not mine, per se, but the IDC lab space has been getting some new toys since the last semester, partially in support of MAS.863, the renowned MIT Media Lab class that teaches fabrication and design skills (which Mechanical Engineering doesn’t have an equal to, by the way). This NextEngine triangulating laser scanner is one of them.

Since this was pretty much my first stab at 3D scanning, I neglected to take more than a few orientation scans (which meant the model had a ton of uncloseable holes in it) and then tried to save it at full resolution into an STL. The result was a 130 megabyte STL file that nothing could open or slice. I had to go back and greatly simplify the polygon count in order for ReplicatorG to even think about working with it.

While the STL just had too many gaps and errors for Replicator to generate a successful tool path (there’s some places that are just totally missing or filled with garbage), the “point cloud” support worked as intended. It looks really messy and disgusting on the outside, but the interior is a regular grid of very fine blobs and lines.

Since the whole point of this exercise is really just to get me a Miku figure clone, I tried it on the venerable Up. It handled the errorful STL wonderfully, though it pointed out to me where each and every one of the missing faces was. This was once again an overnight job…

Miku ended up being 4 discrete solids because of the holes in my model – the scanner couldn’t really capture the detail of the hair joint in the orientations I had it, so the point/mesh cleanup routine chopped them off. And no matter how removable the Up support is, it was still made out of the same ABS and so I had to cut part of her loop antenna structure off to remove the internal support, then reglue it back on.

Her legs are also… uhh, detachable?

But some hot glue fixes both problems.

I’m going to sacrifice this figure by supergluing the joints together so it can stay in one pose, long enough for me to scan it from every orientation. Then maybe I can get a higher resolution and fully one-shot printable model up on Thingiverse.

The bigger lesson here, though, is that I really like the “point cloud” support method. I’ve made so many changes to my Skeinforge settings that it’s not really worth trying to narrate them all here. So I’m just going to upload my slicing settings here (stuff the whole folder into your .replicatorg/sf_50_profiles directory and it should automatically recognize from within Skeinforge.

I’m actually kind of serious about trying an Uplicator hybrid. Pretty much all 3D printers are just a few steppers and a heater or two, so I don’t see much difficulty. They even sell the control board for the Up, but sell the CPU separately…for one hell of a sum. I wonder if that’s just an ATMega chip on a breakout board.

The only issue I see right now is that the Up homes differently than the Replicator – the former homes at “Z maximum” and the latter at Z minimum, necessitating different limit switch placement. In the mean time, Up!

but there’s a catch

With two competent hobby-class 3D printers sitting next to me, there’s something that has been a little forgotten which I will now finally decommission.

Poor Make-a-Bot.

The last time I turned this thing on was in late March some time. Ever since then, it’s been sitting quietly on a table, gathering MITERS grunge. The hardware, Makerbot’s Gen3 boards, and the extruder (a stepper chopped MK5), are generations behind. It was really never meant to be a 3D printer – too beefy and solid, but with my extra-stiff axes and much larger stepper motors I could still hold good resolution even at moderate (50-60mm/s) speeds. It’s really better off as a PCB router or very small mill.

Make-a-Bot isn’t being dismantled. Instead,

I’ve sold it to a hopefully loving new home that will turn it into something else awesome. Bye Make-a-Bot :(

The RageBridgeTwo Breeding Program Begins!

Oct 08, 2012 in Motor Controllers, Stuff

I received the RagebridgeTwo boards literally the day before we left for Maker Faire NYC 2012! Here’s what the whole panels looks like!

That’s pretty. MyroPCB sent this panel to me sandwiched between two scraps of MDF which seems to have been the disposable bed of their PCB drills. I spent quite a while looking at the drill patterns from the other orders and wondering what they were (at least one seemed to be a user-generated breadboard…)

I’m fairly amazed with how well the thing turned out. After the designs posted last time, I made a few more minor layout and trace routing changes in order to be more compatible with Myro’s 2oz design rules. They seemed to want 8 mils trace/12 mils space for 2oz – which seems a little loose, as Advanced Circuits could go as low as 6/6 last time I checked. The trace widths weren’t a problem, but several places had problems with 12 mils spacing between elements.

I don’t think I did a very good job with the space thing, since that would have involved routing almost all the board over again (the gate drive area is a tight squeeze), but Myro ran them anyway and they seemed to all have etched properly.

I decided to make 2 boards out of the panel just to make sure that the routing worked. After all, no use in populating all 10 only to discover that I made a truly phenomenal routing derp (and I didn’t have parts for any more than 2 at that time anyway…)

Now with more FETs.

I’m going to try out several different FETs between these ten boards in order to gauge what the effect on continuous operating current without airflow is. I have the following types:

  • Infineon’s 034N06, 60v and 3.4mohm. These are pretty much the “worst” ones I have – I bought these originally when I was wanting to not blow up 5 dollars every time a FET goes (like I was with the IRFS3107s).
  • Infineon 017N06 60v, 1.7mohm. These are the current choice for Ragebridge and are in all the robots. Conduction losses halved from the 034s. These, along with the 034s, are both compatible with a 36v mode for these controllers. The only thing that limits the hardware to a certain voltage is the choice of FET and capacitor – for 36v operation, I’d want at least 60V FETs and 63v capacitors. 75v FETs would be even better, but they get pricy in low-resistance models.
  • IRF3004-7 type, 0.9mohm, 40V. These will be the best choice, I think, for the standard 24v type RB, but IRF is pricier than Infineon (whose nearest competition is the 011N04of 1.1mohm Rds-on and somewhat lower gate charge).

Once I prove the boards working or otherwise, I’d like to snag some of the new Infineon 010N06s that just came out. Basically, the lower the on-state resistance of the FET, the more current I can push through the controller, so long as the switching time is much shorter than the on-conduction time. Right now, with the 1.7mohm FETs, I can push approximately 30 amps continuous in still air while adhering to a 100 degree celsius junction temperature. If I wanted to edge closer to the maximum temperature of the junction, at 175C, then I can push about 40 amps. Again, this is with absolutely no airflow and no heatsinking effect from the board bus traces or large-gauge copper wiring. Any airflow at all would be sufficient to push the current rating up.

The two test boards are loaded one with 034N06 and the other with 017N06. I only have a limited quantity of the 60v types, so the majority of the boards will be limited to 24v nominal (~30v peak).

Fully populated but not yet programmed. I didn’t even leave myself an ISP header on this thing – that 6 pin header is an FTDI cable connector. So how am I supposed to program the blank ATMega chip? How will I even turn it into an Arduino?!

The answer, as usual, is provided by Hobbyking. Seemingly on a war path to be the next DIY electronics dealer, Hobbyking has recently been peddling everything from said Arduini to robot kits. Aided by the hobby multirotor craze (Yes! There are such things as crazy quadrotor guys just like there are crazy 3D printer guys and crazy electric rideables guys), HK now sells quite a few different flashing tools for microcontrollers. This cute spring-loaded programing socket is a steal at $20 – a similar device from a more “legit” manufacturer would certainly run you triple digits.

And as far as I can tell, it actually works, very well. The springs are stiff, so the pins dig into the chip legs tightly and allow some wiggle room too. Only downside, it seems, is that there’s no orientation guide (that I can tell), so it took me a minute of staring at my Eagle files to discern which orientation to use it in (Hint: Tight group of 3 pins faces away from the dot on the micro).

Seriously. Get that right now, especially if you think you might ever be flashing anything 32-TQFP shaped.

I used it in conjunction with an AVRISP mkII programmer, since I couldn’t get that damned “USBASP” thing to be recognized by my computer or to function at all. A 6 to 10 pin ISP crossover cable was made with some quick breadboarding wire to bridge the gap.

After the Arduino buttloader is loaded into flash, the rest of the program uploads are taken care of via FTDI cable.

I had some fun discovering that “Upload via Programmer” in Arduino means “Erase everything and upload just the compiled sketch” – I spent quite a while probing my RESET circuit to see why my FTDI communications weren’t working, and then it hit me that the damn thing wasn’t even blinking once at startup.

The only changes from the Ragebridge version 1 firmware were some pin definitions, since I had moved several connections around to better suit the chip orientation. Furthermore, the now fully-symmetric current sensor layout meant that one of the current control loops had to be inverted.

What I want to do next with the firmware is to make a “mix” mode for the two input channels, which means you don’t need a transmitter with onboard mixing (or to set it up) in order to use the the controller. Eventually I also want to make it take commands in the form of serial packets (over the FTDI TTL serial connector). However, it will not have any more complications than that – no fancy encoder inputs or selectable analog inputs or kitchen sink interfaces. Ragebridge was designed as a rebellion against those modern ‘universal’ ESCs anyway.

Right now, though, it’s just bone simple R/C servo PPM input.

The one thing which prevents a ‘MIX’ mode from being immediately useful on this board is the fact that I neglected to put any hardware selector on the board. One of the digital inputs can be tied to ground or 5V (e.g. with a PC jumper) to activate mixing, but I just.. forgot to put one on there. Instead, you’d need to solder a wire to a random place with GND, which isn’t very useful.

These, and other random layout shortcomings, will be addressed in a 3rd board revision.

In anticipation of possibly having to test 10 boards, I went ahead and designed myself a jig. Similar to a bed-of-nails tester, it just holds a bunch of 3.5mm bullet connectors in place to make all the important power connections (bed-of-bullets tester?!) so I don’t have to solder 8 wires every time.

Here are the connections completed. Inputs and outputs are both my standard 4mm bullet connector interface. A 3.5mm bullet just happens to squish enough to fit into the wire holes on the board, so…

Board #1 under test. Conclusion: it works.

Whoa, I assembled a board, totally untested in the middle of the process, and it works on the first try. That’s actually pretty damn new and exciting.

The second board had an interesting problem where one PWM out was seemingly underflowing repeatedly, very quickly. A bit of probing led me to discover that one of the current sensors had died (or was dead to begin with) and so was pegging at 5 volts. Constantly triggering the overcurrent procedure, it continually decremented the output PWM command, went past its valid ranges (+/- 255), then underflowed its signed int holder and kept decrementing from the top again. This caused the motor to occasionally freak out as the output command entered then exited the valid range.

The spazzing also damaged one side because it was while the board was hooked up to a non-regeneration-friendly power supply. I fixed it by replacing some gate drive components, but I guess now I know which board I am hanging onto!

The test motors were an EV Warrior and a derpy 24 volt scooter motor. Basically the test involved alot of slamming the motors back and forth (on a battery, of course) after validating controller functionality on a current-limited power supply. This was  to test if the controller was sensitive to pulsed current-induced noise, and if the smart current limiter was working.

Alright, time to start on the next set of boards. This is like 5 hours of solid work, and in the end, I totally ran out of parts! I’ll have to wait until the next Digikey order comes in before starting the soldering process again. First to run out were my gate drive zener diodes, and oddly enough, 1uF capacitors. I also ran out of ATMega chips and gate drivers.

The development process for this thing is starting to get reeeeally expensive. I have yet to total up the cost per board in this quantity, but the chances of me giving away free samples to alpha testers is very, very slim.

Once I get my refill orders in, I’ll populate and test the rest of these boards, and then set up the structure for an alpha testing run. I intend on releasing these “into the wild” as much as possible in order to find their limits and how people are going to mess up on using them. The guidelines below aren’t set in stone, but are what I have in mind as to what would make a good alpha tester:

  • You have a device, whether it be a robot or vehicle, that uses 2 DC motors in some way. Right now. Not “will in a few weeks or months”.
  • Your system runs 24 to 36v. Up to 48v is possible, but I would need to specially configure a board for it. HV testing is something I’m interested in doing.
  • Your system usually pulls 30 to 60 amps, and can live with 60 amps at most (This means some high-current systems like Magmotor-powered go-karts will experience constant-current mode for longer).