Archive for the 'Project Build Reports' Category


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).



Maker Faire NYC 2012: Infinite 3D Printers, Chibiing in the Rain, and More!

Oct 03, 2012 in Events, Project Build Reports, Stuff

Alright, here’s the grand report from the World Maker Faire NYC! As previously reported, I journeyed down with a pile of undergraduates and a tower of Chibis:

The trip to Queens took about 4 hours each way, and I pretty much made everyone listen to Hatsune Miku the entire way. I’m truly sorry, guys.

On another note, everyone who came with me have blogs full of fun build reports and pictures: Ben, Banks, Cynthia, Nick. Also technically in this picture, but buried behind everything and forming the basement and ground level of Chibi Tower is Nancy’s Giant Hexa(rideable)Pod.

We actually loaded 2 large cars to the brim with creatively tessellated things and people for the trip. I’m a fond fan of floor-folding seating for minivans, to the point that the Chrysler Town and Country is actually one of the very few cars I would actually buy (you know, instead of build).

The only things I ended up bringing and showing were the two Chibikarts. While Kitmotter came along, as reported initially, I never took it out for the weekend save to show someone what was inside a hub motor. RazEr Rev also did not make it into the pile. Overall, I think not spamming projects contributed greatly to me being able to… actually look around the faire and enjoy it and stuff.

Here’s everything, and everyone, unloaded and unfolded/reassembled. Let’s count: 6 scooters, 3 go-karts, 4 multirotors, a hexapod, plus DGonz’s robots. In terms of highly mobile electric powered objects, I’m gonna say that MITERS pretty much dominated the field. And that’s just what came down with us – after the day got started, the oneTesla crew and Team Blindlead, among others, also arrived.

One thing I was kind of tired of from last year (and demos in general) was answering the same questions over and over again. I don’t mind it to a certain degree – however, the same trends inevitable crop up: What batteries does it use? How fast does it go? ….is it solar powered?

Out of interest towards answering more in-depth and meaningful questions, I made these cute little stand-up signs with a few minutes on the laser cutter. The local stationery stores tried to charge me $10-$15 for a bent piece of acrylic that holds a sheet of paper, which I was less than enthused about. The signs have basic info on the project.

I estimate that they deflected about 50% of people who were superficially interested, and the questions that remained were somewhat more high-level, asking about how the motors worked and what controllers I used, as well as if I sold kits or plans. You people are really going to make me do this, aren’t you?

The placement of the MITERS table this year might have coupled significantly into the spread of questions, though. Last year, we were in the “big tent” where many kid attractions and organized Maker Faire events were taking place. This year, we were in the mishmash of hackerspaces and individual maker groups on the other side of the event. Many kids and parents, I think, were diverted towards the ‘tourist’ events. Only the more brave parents and fellow hackers/makers tended to peruse the hackerspace groups closely, it seems.

Alright, I could post a pile of pictures about what a Maker Faire is, but it would be duplicating the many other photo galleries on the Internets (including the official). If you haven’t been before, then I recommend finding a maker faire (or mini-maker faire) around you. I’m going to instead focus on the things which I took away from this event.

3d printers and open source hardware

The first thing I noticed was there were alot of 3d printers.

Like, way more than last year.

Here’s some that look to be half-Ultimaker and half… Hey, is that a un-shelled SuperMake-a-Bot?!

By the way, that’s a never-before-seen picture of the design. That is as far as I got on it before it was abandoned, and I never made the final post regarding it. I *almost* want to keep going now…. Pretty much everything was figured out at that point, but the project was dropped due to lack of originality or improvements on the previous generation, and for being ass-expensive.

Yeah, lots of 3d printers. This one’s an Up! Mini which debuted earlier this year. It, as far as I can tell, is an Up! in a box. Well, with other mechanical improvements like stiffer axes.

Alright, you people are just fucking with me now. From a Shenzhen operation is the Weistek WT2, which seems to be either creatively-restructured MaB or a larger, metal shell-less Thing-o-Matic (which is basically what MaB is anyway). The guys at the booth didn’t really speak English – what info I could extract from them in Chinese basically confirmed my theory that it ran all OS stuff including Makerbot’s Gen4 electronics.

I’m clearly not the only person to notice that there were a whole lot of 3D printers. Here’s an entire Make post dedicated to them. There are, if I haven’t made it clear, a lot of 3D printers!

What I found more interesting and more distressing was the fact that so many of them were making the same open-source thing. In a few cases, they are clear derivatives and straight up knockoffs being marketed as originals with no acknowledgement to prior work. Like that pile above. I really did a double take when I first saw that table, and had to ask myself if I was in fact in the Makerbot camp. Nope – Makerbot was behind me at the time demoing Replicator2s, and these were clones of the MK7 extruder and their related components.

Part of what spurred my interest in checking out the guts of many of the demo machines was the controversy over Makerbot going quasi closed-source with their new Replicator 2. If you missed the near-riot that occurred on the Internet as a result, there are plenty of strongly worded letters and appeals to Open Source that are definitely worth reading and thinking about. The OSHW community is basically being forced to recognize the existence of ‘design freeloaders’ now that Makerbot, one of the champions (or former champions, whichever you prefer) of high-value and high-complexity OSHW systems that are commercially available, has embarked on a seemingly more conventional entrepreneurial path, and that perhaps it’s time for the Unspoken Rules of Open Source to be publicly discussed. There’s alot of sides to the story, but I’ll take this moment to discuss my own perspective as someone who generally throws everything he designs up on the Internet for your amusement.

1. I support Makerbot’s decision to become more consumer-focused and to create better products

In product design, especially machines-that-make-products design, one of the worst things you can do is involve end-users in the manufacturing process. That opens up an entire world of manufacturing variations that could make your machine not work or work so shittily that people think it doesn’t work anyway. The goal of most industrial processes is to produce 1 part with 1 machine operation with zero variation between parts which last 100% of their designed lifetime and no more. Many studies have been done, papers been written, and theses been founded on manufacturing variability and waste/reject management.

But that’s no fun at all, IMO – the infimum limit of this function, in my mind, is Apple products. It’s not something that I think anyone should ever aspire to become, because not being to make your products fixable at all is just not cool. The other side of the coin is all the do-it-yourself 3D printer kits on the market these days which require many hours of assembly and fumbling small parts, in which the end user can introduce so many variations in both assembly and operation.

I’ll venture to say that 75% of the Repraps and Makerbot Cupcakes / Thing-o-matics I’ve seen are poorly tuned or built and as a result return only mediocre prints. It took me days of poking to get MaB to perform on-par with a well-built ToM. In Makerbot’s own words, it takes 8 to 9 hours of their support to build an average ToM from kit. When you sell to everybody, you no longer have the security of your audience being all highly-skilled hackers and modders who will take circuitous routes around a design or assembly problem. I was perfectly fine with performing 2 hours of tuning and software changes on our allegedly tested and working Replicator 1 and still calling it reliable and ready-to-run. The mentality is different for those of us who have a long hacking history versus beginners or people who saw someone else with an assembled kit and figured they could wing it.

To make your product work for all the possible combinations of things that could be put together wrong or not quite tightened enough, you have to compromise the functionality of the design. Things have to fit loosely so anyone with a laser cutter that may or may not have a fried lens and is running an inch out of focus can still cut it successfully. You have to use generic parts which are available at at hardware vendors, which may involve an indirect path of functionality to accomplish a relatively simple task (the many different 3D printed carriages for RepRaps come to mind). Kinematic coupling really only works if your base material isn’t prone to warping due to humidity and temperature (*cough* plywood) because it has to be easily obtainable.

Sure, it’s no fun to us as hackers if someone makes a product so streamlined and customized that it can barely be modified or chopped to our content. But that’s not going to be what 99% of people want. We are not the 99% when it comes to finished products, we are the 1% that is willing to suffer a bit of hammering for a chance to learn how the product works or to satisfy curiosity. But then the hacker market is necessarily constrained and easily saturated with similar products, which is why you have to keep moving and innovating. I’ve noticed that the OSHW community also takes “innovating” to be a rather constrained ideal of making the next new cool thing. Which it totally is, but making the current thing better or the past thing up-to-date are entire other axes which I think are underappreciated.

I’m not saying that building good product is entirely orthogonal to making it have hacker appeal, but to minimize your support time for every working machine involves taking out the end user as a source of errors, and this in part leads to the proprietization of hardware because it’s simply easier to accomplish the task (building working machines) that way. Especially if it’s not just you hacking away on a weekend, but a company that needs revenue to keep on rolling.

So that’s the long part of this polemic. I’m a fan of newer and better things from 3D printing companies even if I don’t get to directly build them. So long as Makerbot doesn’t start gluing their motors in or using pentalobe screws, I’m chill with them. As someone who maintains a handy database of mechanical engineering skills, I’m still more liable to building my own than paying 4 figures, but hey, I’m not part of the intended market.

2. I believe that the hardest part about designing a new product is the origination of the idea.

Everything else is derivatives, refinement, tweaks, and little variations. As someone who has generated dozens of original projects, I will say that 90% of the effort is spent grounding the design at a single point (deciding where to start the damn thing) and then building the first iteration. The rest of the time, provided you don’t just straight up start over, is spent making the thing actually work and not blow up when you plug it in.

I understand the frustration, then, when you see your project and work cloned by someone else without consideration for any of that initial design thrust. I’m not talking inspired works or even my undergrad and high school aged peers building variations of my projects. That’s for their own learning and amusement – recall that Make-a-Bot was a straight up cleanroom clone of a Thing-o-matic after I saw one at Maker Faire NYC 2010 and wanted one.

But never did I try to pass it off as something I designed and made from scratch, and hell if I tried to sell it. That’s not the case with the 3d printing outfits I saw at Maker Faire. The greatest offender to me was pictured previously with their pretty much straight knockoffs of MK7 extruder parts. I chose to not ask them the hard question (“Hey, this design looks kind of familiar – any other machines similar to these?”), but I think I really should have.

It may be true that they figured out how to make the extruder body from a cheaper plastic (UHMW, instead of ABS) that was easier to machine, and outsourced production to China for lower price. And it may be true that instead of a custom hobbed drive roller they literally took brass gears and cut a little groove in them, but that is skimming the 10% of effort away from the 90% that went into designing the original MK7.

So many other designs were blatant pulls from the Reprap project (Josef Prusa himself had 1 table, away from the 3D printer village, on which was parked 1 Reprap. Guy couldn’t even speak because he had lost his voice) with no attribution whatsoever – pretending that they were totally novel developments – that it was indeed very disappointing.

I’m totally aware that Reprap’s OS nature lends itself to this kind of thing, which is why I’m not entirely okay with the idea of open-sourcing everything. In my opinion, the core technology that forms the foundation of your product should not be shared freely unless you really were not in it for the money. Alot of people say they are not, but when these clones start arriving and they get hissy, it’s clear what the main motivator is because at that point they are either drawn by the lucrative market or too heavily invested to just let knockoffs slide. Speaking of investment,

3. Open-source software people and open-source hardware people work in essentially disparate domains, and even then, a 3D printer is a far cry from an Arduino board.

I have always had a beef with open-source software people. There’s tons of them around MIT, trust me. Oh, and all open source software sucks. Seriously. All of it. Generally they try to replicate the function of a closed-source software but with harder to use interfaces (no, I am not going to diddle with a command line, and don’t even get me started on OpenOffice) and inconsistent documentation mostly made of “run this linux script in a shell”. It’s usually made by 1 dude and his friends, and hosted on Git.  When it comes to software, I *am* that 99% of end users and I will not put up with mostly-working bullshit.

But enough about me, and more about the software. Software is cheap and easy because you just need a computer (a generally mass-produced item whose manufacture involves no end users, because damn if the computer you bought doesn’t work, right?), knowledge, and time. This explains why at the MIT Career Fair this past month, a solid majority of companies present were software startups and established software companies in some way.  Software is so cheap and easy, in fact, that MIT’s EECS department is starting to complain that no students want to do hardware any more, they just all want to work for/start the next Facebook.

What is different about hardware? Hardware needs to have a physical embodiment. Something needs to get made, and something else needs to get appended to it in order for the thing to work. As of right now, I cannot wish an object into existence, though the Replicator comes pretty close. But even that had to be manufactured and assembled somewhere, and the ABS filament it extrudes came from some oil well in the ground and had to be refined many steps before it could become my (unit linear) quantum of solace. My point is that the amount of resources that are irreversibly committed to a hardware project is much, much greater than a software project. With software, at worst you lost on the opportunity cost of pursuing a failed project. While that could certainly lead to doom, if you bust money on hardware that fails or doesn’t sell, you have immediately lost physical resources. The level of commitment of hardware is far different from that of software, and from my reading of the poetic floor wax of the recent OSHW debates, it is something that OSS people do not seem to understand.

The strongest opinions on Makerbot seem to be coming from the software end of things. Much comparison has been made to the Arduino project staying open source even in the face of clones from China and “-duino” derivative projects. But here’s the thing about such comparisons – it’s way, way easier to stuff a board than design a mechanical product (nevermind mechanical products with integrated electronics).

An established chain of tools exists for stuffing a board: Generate a set of Gerber files using your favorite design program, send it to a board house where a magical machine (with decades of history) uses your files as an image as a mask to etch copper where it shouldn’t be. The copper is washed and cleaned (automatically), holes and drilled and vias are packed (automatically), and the whole thing is dunked in a bath of solder to plate it. After that, provided that you’ve supplied the board house with your bill of materials and ordered the parts, the board is automatically filled with components by a pick-and-place machine and then automatically soldered in an oven. And this works, 99.9999% of the time, or else Foxconn would be out of business.

You cannot do that with a mechanical part. Take this picture of a simple motor mount for Segfault:

It’s a plate with holes in it. How simple can it get?

I can think of 3 different ways involving 3 different machines which can be used for this part if I wanted production, and that’s only in the time I wrote the last sentence:

  1. I can use a waterjet, like I did above. Waterjetting typically costs $120/hour, a machine is usually a cool quarter-to-half-mil, and I’d need a commercial 3 phase 480v electrical hookup to use it in the first place, and that ain’t cheap. This would make some sense for low quantities, like 1 to 10. By the way, Big Blue Saw is totally a thing.
  2. I can hire out the part to be 2D profile milled using a conventional CNC mill. The finish on the side would probably be way prettier and I can light the resulting chips on fire for amusement. 20-30 parts can probably be tiled into a single plate of aluminum and the machine would probably pop them out in under an hour with modern high speed machining. The machine can be fed by a technician and so maybe 200+ parts is reasonable for a day. We’re not talking exotic high-speed 5-axis CNC here.
  3. If I needed to make 10,000 a day, then I would have tooling designed to be used on a progressive punching machine where literally 1 cycle can produce 1 part. That tooling, again, can be made in many ways depending on who I contract it out to exactly and what machine that have, and what tolerances I care about, and what material I really need (can I get away with a softer metal to ease on tooling wear?)

What I’m trying to say is that hardware is way more involved than software – again, an issue of resource commitment. I can’t hit recompile on that motor mount after the $150/hr CNC technician has finished half the run of my parts on a machine which costs the company another $200/hr just to keep running. Part of the wonder of rapid prototyping tools lies in the fact that it is wholly within reason today to make exactly 1 part and be done with it. This explosion of design pathways is part of the reason why automatic quoting systems for 3d conventional machining have been much more difficult to make – I’ve yet to see anyone pull off a Big Blue Saw-like interface  (FirstCut is pretty damn close, but look at that pricing. Upload a solid model of a cylinder and see!) for CNC machining.

So I disagree with the attacks on Makerbot using Arduino and other OSHW boards as examples. It takes many real revisions and failed hulks of prototypes to make a working machine on this scale, and therefore you have far more to lose when the resulting effort is cloned 1-for-1.

What’s the message I’m trying to send with this hopefully perspective-enhancing piece? I’m not aiming to swing the Internet Backdraft towards any one direction, but hopefully the opinion of somebody who deals mostly in machine design and hardware design will add to the discussion which seems a little one-sided towards software and electronics hackers right now. I hope that will help solidify what OSHW stands for and aims to promote. As a closing statement, I direct you to the useful stuff section of my site.

Anyways, onto more fun things, like…


One novel event for this NYMF is a run of the Power Racing Series which took up a fair chunk of the NYSCI parking lot.

I’d been contacted by the event organizers beforehand asking if I wanted to run Chibikart as an exhibition, since they weren’t expecting many entries. With pretty much all the silly MIT vehicles in tow, we couldn’t resist taking a few runs at the track. Above was an impromptu “2 wheeled race” that happened on Saturday.

I had a little too much fun with Chibikart 1. It’s now sporting two completely toasted motors as a result of my drifting antics. The left side wheels are also pretty much ground down to the plastic. I found that the combination of a slightly wet ground (It was raining for some part of the weekend) and actually heating the tires up through turns made Chibikart very easy to controllably put into a lift-off oversteer induced drift. Pretty sweet, but unfortunately it doesn’t really have the torque to follow through, so it’s still more of a powerslide.

Chibikart 2 faired substantially better, and was actually more squirrelly – I spun it out a few times in the turns. Both of them also got disgusting because the rain had turned the usually quiet dust and debris on the parking lot surface into a nice liquid grime. Everybody who raced looked like they were actual open race car drivers by the end – covered in crud.

Chibikart 2 and tinykart tag-teamed an entry for the long endurance race on Sunday, which was essentially both of us running batteries to empty repeatedly because we never figured that these things were going to go more than 10 minutes at a time. On one occasion, I attached a tinykart battery to Chibikart and actually just held it in my lap for those laps. In the end, Team-unofficial-MIT finished 122 laps and was “4th place”. Now, we couldn’t actually win anything because the vehicles were totally not to spec and were entered in the event at the discretion of the organizer because they were in need of cars to fill the track.

So I must therefore officially protest the abundance of “We won over MIT!” chest-pounding that seems to be found in the highlights videos from several teams, including the official race promoter video. We challenged someone?!

While I recognize that being from a place like MIT inevitably means that we are viewed in psychological competition every time we do something in a large crowd (Georgia Tech gets similar heat, especially at Robot Battles), and that drumming up a little hype is not bad for an event, come on man. I’m totally into the idea of building a to-spec Power Racer after watching and participating, but the reaction from fellow competitors when we enter unofficially doesn’t bode particularly well for an official entry, nor is it particularly welcoming and liable to making me help promote the sport.

We conclude with a picture of Fort MITERS, constructed in about 5 minutes when it suddenly started pouring on Sunday.

The Pre-Maker Faire Madness of Chibikart

Sep 29, 2012 in Chibikart, D.P.R. Chibikart, Project Build Reports

Along with most of the rest of MITERS, I’ll be party vanning down to the New York Maker Faire on…. well, now. It’s this weekend.

Like last year, I’m hauling an immense pile of MITERS cargo in addition to a few hapless freshmen and sophmores (who I think count as cargo anyway?). Last time, I brought Landbearshark. This time, I’ll be bringing something about equal in mass but a little more fun: Double Chibis! Tagging along also because they fill space efficiently will be RazEr REV2 and Kitmotter Display Stand.

There go any chance of flying down the hillsides at the NY Hall of Science though.

The Chibikarts, unlike most of everything I build, have been working rather reliably. Chibikart 1 suffered 2 broken motors when MITERS used it for Orientation activities – I’m not really sure went on, but the front two motors were just totally unresponsibe – but the controllers were fine. However, Chibikart 1 still worked with the 2 rear motors, so that’s been its demo state for most of this month.

Last week I decided to crack them open in anticipation of repairs for the NYMF.

Well damn. It looks like my somewhat hastily-soldered phase star-point connections exploded. The solder joints became little balls of solder – indicative of a serious current overload or something. Either way, the damage to both of the motors was similar, so I just re-terminated them. I coated the windings in a thick layer of polyurethane varnish that the high-voltage crew at MITERS like to seal their Tesla Coil secondaries with.

A few days ago, Chibikart1 was involved in a…. “filming accident”.

While I was in the middle of the Poorly Coordinated Death Spiral, the right front motor lost power and started smelling real funny. Upon opening the motor again, I discovered that the windings were actually not burnt – but just shorted. As I unwound the stator,huge chunks of the magnet wire insulation were flaking off and coming apart. I was literally pulling lengths of bare wire from the stator.

My suspicion is that the urethane varnish damaged the insulation of the wire either by being too tenacious (typical cheap magnet wire with sub-300 celsius insulation rating are coated with polyurethane-based enamels) which caused the insulation to prefer the urethane coat instead of the wire, or the solvent was too strong and dissolved or damaged the insulation chemically.

Bottom line is, don’t seal your motor with urethane if it has wires made of urethane. On a similar note, titanium screws in titanium threads will degenerate into the slightly less useful case of a solid blob of titanium.

What was worse, actually, was that the urethane sealed the whole stator into a solid mass of wires. I could not hope to ever unwind this without baking or chemically destroying the urethane in some way. The magnet wire strands just broke off as I tried to pull on them.

I had to rewind both of the front motors, which didn’t take that long since I was used to it:

To give the wires one more layer of protection, this time I insulated the crossing strands with some Kapton layers.

Completed rewind. I decided to group the star point connections into one termination this time instead of attempting to solder a ring of wire around the outside of the windings. The whole mess was coated in epoxy (like I should have done to start with…), and Chibikart 1 is now kicking again.

Chibikart2/DPRC has received no mechanical mods or upgrades, but I did jump the shunt on the 350W Jasontrollers a bit to give it some more punch. Because of the ~25A constant current limit of the Jasontrollers, DPRC is actually a little anemic despite having higher potential power. To really use those motors, I’d need some sensor boards (hmm, I wonder where I could get some) and use higher-current Kelly controllers.

Come see Chibikart and DPRC (and RazEr & co.) at the MITERS display area in the Hackerspaces area (Zone B) at NYMF!

Oh yes, a preview of things to come:


Some more random boards: The sm00thsensor Project

Sep 23, 2012 in Motor Controllers

In keeping with my promise of not building anything else huge and parking-requiring this semester, I’ve been investigating in more detail some other potentially useful electronics projects which have been the products of discussions with peers as well as my uncalibrated imagination. This is one idea that has been in on-and-off development for a while.

(Also, buy my stuff.)

One thing that we like to do around this neck o’ the silly vehicle woods is to append Hall Effect rotor sensors onto motors which don’t have them. The majority of industrial brushless motors have 3 Hall sensors embedded in the windings in order to pick up the position of the rotor magnets – this is so that the controller can switch the windings in the correct order, even at extremely low speeds. The sensors essentially become a 6-state absolute encoder. The positioning afforded by this is extremely coarse (for instance, the example 3-slot, 2 magnet pole motor in the link will only have 60 degree positioning clicks), so for high-precision applications like robot arms and CNC servos, this is usually backed up (or totally replaced) by a sinusoidal resolver or much finer optical absolute encoder.

Plain old sensors are well-suited for vehicle traction purposes, though, where the motion is generally in 1 direction and whose timescale of change is much greater than 1 motor electrical cycle – the motor usually has to apply a few seconds of effort to get the vehicle up to speed. Pretty much all e-bike hub motors combine Hall sensors and a very high tooth/magnet poles count to get super-smooth motion at low rotational speeds.

sensors on r/c motors

For indirect drives that use stock or modified R/C style outrunners, adding sensors needs some creativity. There’s usually two approaches: putting them inside the motor and mounting them externally.

I generally favor the inside approach, in part because I usually construct hub motors (with few exceptions, you can’t sense externally with a hub motor). However, fixing the sensors inside also has disadvantages.

  • You have to know how the windings are disposed. The sensors need to be in key locations between phases (putting them accidentally in between 2 teeth of the same phase means they are always mistimed by 30 electrical degrees) and this is only possible to find out if 1. you wound the motor, or 2. you have a sensitive enough magnetometer to check each phase to see which direction the teeth’s fields are pointing.So, it’s riskier than externally mounting them because you have to crack open the motor again in order to fix it if you got it wrong – plus, the motor will totally run like this if the right combination of phase and sensor wires are achieved, but it will sound terrible and draw much more current to produce the same torque, because some of the current is wasted on firing the windings at the wrong time.
  • There is no ability to fine tune the sensor location to account for timing errors caused by sensor hysteresis.

The sensor boards that I’ve been using and which are occasionally seen on this site are custom made with angular slots to allow easier “combo finding”, since I did not wind those outrunners and therefore their internal layout is a mystery. They were developed for “2.00EV“, which ran entirely off the principle of using R/C outrunners, and I judged sensored control to be the more reliable method.

The second issue is one which is concerning for vehicle traction that needs to be bidirectional (i.e. have a reverse). I’m not sure if it’s just not been noticed because most R/C motor modified vehicles don’t ever go backwards (e.g. bicycles) or what, but on vehicles like Landbearshark and tinykart the issue of hysteresis-induced timing error can be quite severe.

The majority of hall sensors employed on motors are “bipolar latches”, which means they have 2 states (outputing high/low, coresponding to ~5v and ~0v for the usual 5v system), and they flip between those states whenever the magnetic flux density sensed goes above or below internal thresholds:

from the Allegro A1250LUA datasheet

Above is the state diagram for the A1250, a common hall sensor. For this sensor, Bop is approximately 5 gauss – when the field strength exceeds this amount, the output will pop low. It will not return high again until the field reverses directions and exceeds -5 gauss. These are “typical” specs – the maximum band is +/- 25 gauss, which leads to a hysteresis band of 50 gauss.

With the sensors being on the outside of the motor and trying to sense the magnets through a steel can, every little bit of field counts. I’m lucky that R/C motors are made so cheaply that the rotor is not thick enough to fully contain the magnetic flux. The field from the motors looks vaguely like this:

…by the way, here’s an actual magnetic field simulation made using the FEMM software. You don’t see as much leakage in that one because the rotor is thick enough that pretty much the entirety of the field is contained. (I’ve also wondered how much more torque per amp you can get just by wrapping another layer of steel around the typical R/C motor, but that is an aside.)

The message that my sketch is meaning to convey is that at each point where you can measure the flux density (“strength of the field”), there is a tangential component and a radial component. The only thing that the Hall sensors detect is this radial component. This is where the hysteresis of the sensor can introduce timing errors.

Say that the radial field at the location of the arrow head is -25 Gauss, and is where the hall sensor switches states. For the sensor to switchback to its original state, it has to travel all the way across to where the radial field is +25G. In the above drawing, the mechanical distance (in degrees) between these 2 points is about 5-6 degrees. Not a big deal, right? But because most R/C motors are 14-pole “LRK” motors, the equivalent electrical degrees of that error is 5 * 7 (pole pairs) = 35 electrical degrees.

What that means is if I moved the sensors to trigger exactly on-time for one direction of rotation, it will be 35 degrees too late for the other direction. It’s pretty much ‘magnetic backlash’ to use a mechanical analogy. The ideal hysteresis-free sensor would switch exactly as it crosses the midplane between the two magnets with no delay. This can actually be a pretty big deal. A few degrees of timing error might just result in a lowered top speed and more current draw, but 35+ degrees might make your motor just straight up not reverse or have issues starting. 25 gauss is also really goodfor a Hall sensor latch – the ATS177 type I typically use actually have triggering thresholds of +/- 70G with some specifications having +/- 100G.

Shane did a very thorough investigation using a strobe tachometer of this phenomenon when it is applied to externally-sensed r/c outrunners in traction applications if you want to see how bad it can get on video.

how fix

One idea I thought of which would fix this would be to use hysteresis-less sensors.


Smart, huh? It’s what I went to MIT for, duh.

Well, the real explanation is slightly more complicated. Instead of using digital latches with their own hysteresis bands built-in, I would instead use analog (linear) hall sensors which output a varying voltage, typically 1 to 2 millivolts per gauss centered around half of the logic supply voltage (VCC/2).

However, just using them by themselves is not necessarily enough, because the logic that is reading the sensors usually has digital hysteresis by itself. For instance, the ATMega328 microcontroller’s input thresholds are 0.3*Vcc for low-going transitions and 0.6*Vcc for high-going. Not only is this not symmetric around 0.5*Vcc, but the band of 0.3 Vccs is 1.5 entire volts for a 5v system. If my linear hall sensors are 1mv/gauss, then that’s a hysteresis band of 1500 gauss. That ruins the point. I’m fairly certain that is actually way worse than using digital sensors. The asymmetry would mean that the Halls are not “on” or “off” equally, so the motor will prefer several states over others.

The solution I settled upon was to pass the linear hall sensor outputs through a fast, low-hysteresis comparator which checks the input voltage against a Vcc/2 resistor divider made of 0.1% ultra-tight tolerance resistors.

The comparator I chose for this task was the MAX9034 4-channel comparator, which was selected mostly by stochastic Digikey-ing (I have no particular attachment to this part number), and the hall sensors are Honeywell SS49E linear types. I had to go with a TSSOP chip, which will be bitchy to solder but was the only size that could really fit on the board.

The idea is that the comparator’s internal hysteresis is the only discontinuous element in the system, and that is almost vanishingly small. For the 9034, it is 4 millivolts, which translates to 4 gauss or less depending on the actual sensitivity of the Halls. The output of the comparator will be a fast-edged square wave feeding into the logic and skipping over its hysteresis band.

Here’s a picture of the board. I’m starting with 63mm motors since tinykart is an excellent plant for validation of the idea, and it uses the 63mm class outrunners formerly retailed by Hobbyking (now retailed by Leader Hobby).

It uses the same adjustable slots as the current generation of sensor boards so it should be a drop-in replacement in most cases.

I sent the board to MyroPCB about 2 weeks ago and had them panelize it:

And last week, they arrived!

Sweet, that means I can get to testing them, right?

I wish. Alot of this design and thinking was performed several months ago, and I ordered all the parts then, but not the boards. Problem is, I’ve since lost the Hall sensors! That was like 50 bucks in sensors…

I had to reorder them, but they did’t get here in time for the weekend. Ideally I’ll have the sensors in-hand tomrrow and can get to populating these boards. Then, testing to see if I am bullshitting myself.

other sensor boards

Besides these super special ones, I’ve also updated the designs of the 2.00EV boards. Not only am I going to make another run of these boards for next semester’s 2.00gokart where everybody will need them, but I fully intend on selling these on this site too. These are just plain digital latch boards, suitable for one directional movement. I’m also working on some mounting rings that fit the 59-80mm common outrunners for the complete value-added package.



The Triumphant Return of the Ragebridge: RageBridgeTwo

Sep 14, 2012 in Motor Controllers, Project Build Reports

First, in accordance with the Charles Z. Guan Strategic Stuff Reduction Act of 2012, I’ve opened up a listing page of things I’m clearing out. Let me know if you want a thing. As I continue mining through my multiple mid-dens, more things may be added.

Now, onto the real content.

With the version 1 of the Ragebridge controllers having proven themselves at Robot Battles 2012 (after being the stuff of nightmares prior to that), and now that I understand what I’ve been doing wrong the whole time, it’s time for me to make an update which addresses the little shortcomings and fine details that were lacking in version 1. Recall the major hardware issues:

  1. Gate driver bypass caps were placed incorrectly, thus causing the gate drive power traces to have higher impedance to pulsed currents, with the resultant voltage spikes some times causing instability.
  2. Gate drive current return path was long and loopy: through the main power ground, and back in through the narrow logic regulator trace.
  3. Non-rotationally symmetric current sensor placement meant there was a major current bottleneck for one side
  4. Long power traces in general made for more bottlenecks
  5. The logic regulator inductor was (and apparently has been in many of my past designs) too small which caused the regulator to become unstable.

Luckily they were all solvable with component-level hacks (no more wire cutting and trace jumping!) so I can easily roll them up into an upgrade. Next, there were a few little gripes I wanted to resolve which didn’t impact the function of the board so much as was just annoying.

  1. None of the 3-pin digital input headers had the correct orientation for standard servo cables. I had intended to make 2 of them “potentiometer” style inputs, reading [5v] [Signal] [Ground] from one side to the other, and 2 of them R/C style inputs reading [Signal][5V][Ground], but messed up (and didn’t check), making the latter two [Signal][Ground][5V] instead. Basically this meant I had to hard-solder pigtails to the board so as to not plug in a normal servo cable and explode everything.
  2. The board is 2.2″ wide, which precluded it from fitting vertically (space-saving) in a 2″ frame, fairly standard for the 12 and 30lb classes. Only Clocker could fit it vertically in a custom little “rack”.
  3. It still uses that ATMEGA328 breakout board called the Arduino Nano. Not only is that kind of unnecesary, but the thru-hole package of the Nano actually makes routing pretty difficult since I have to fit signal traces between the thru-holes.
  4. I could only read 60A peak with the “single bypassed” ACS714 current sensors. With a little help from a fan (and maybe 4oz copper) I don’t doubt this board can flow more than that.

With these issues in mind, the goals for RB2 were clear:

  • Squish the design down to 2″ wide maximum
  • Rebuild the schematic from scratch to eliminate possible cross-generation schematic copying problems, which is what led to my incorrectly placed buscaps and ignorance of the logic regulator problem for so long.
  • Widen all the power traces and make sure all the gate drive traces have their own low-impedance path back to the driver chip and the power supply
  • Make the current sensors “double bypassable” to read peak currents up to 90A and make the layout as much of a 180 degree rotation as possible to preserve the bottleneck-free layout.
  • Board-mount the ATmega328! It’s still going to be Arduino, but I’ll forego the extra $12-20 breakout board.

It’s also important to note that RB has been printed on 1oz copper using the cheap prototyping service from MyroPCB. Even moving to 2oz copper would help alot with the current bottlenecks. Ideally I’d try to get it fabbed from 4oz copper.

Here’s the first shot of the layout progress. The master layout remains essentially the same. The board is now 4.5″ long and 2″ wide:

Beginning the layout is usually the hardest for me because that’s when the problem is totally unconstrained. I usually jiggle the major power components around in a rough grid snap (to ensure reproduceability) first. After that, I usually work from the “outside in” – gate drive components get arranged next, then the logic fills in the loose volume. I’ve gotten all the way to the “so, where to put the logic components?” stage here, so they remain in a formless blob in the center. It does show that I have space to play with however.

For the ATMEGA chip, I knocked a footprint and schematic symbol from the Sparkfun Electronics library. The one difference is that I added to the ATMEGA’s pin names in the schematic their equivalent analog and digital pins when the chip is brainwashed into Arduino mode. This just makes mapping from old to new schematic easier. I’ll update my EAGLE Library under the Useful Stuff / references page with this device.

There’s one more little detail about this board, but I’ll keep going for now. Let’s see if you can figure it out.

I’ve now added some of the major power planes and a logic ground plane. One of the things I’ve never done in the past is a logic ground plane, for some reason. It makes trying to tie all the ground nets together so easy! And a wide plane is lower impedance than narrow 10 mil wide traces hopping through 9 vias. I just had to be careful with the bottom-layer traces not cutting the plane in half or totally isolating a ground pad, which would defeat the purpose.

The big SMT 6 pin header has disappeared – it just took up too much floorspace.

A few hours later, the first round of iteration is complete. Really I should send the board out to manufacture right now…

…but I decided to wait a while this time. I didn’t do anything with the board for about 2 days, upon which I returned and started optimizing. The differences are very minor, mostly in component fine placement. There’s now plenty of room to attach standoffs to the board at its mounting holes. Furthermore, the mounting holes have been made into a slightly smaller square that is the same size as a 52mm DC fan’s mounting pattern. This means I should be able to get some active…. microcontroller? cooling going on with this board.

Even though I say microcontroller (the ATMega would be receiving the best airflow in the house), almost any airflow at all would make the FETs’ thermal resistance to ambient air lower and hence increase the current rating of the board. Maybe there’s enough space to fiddle with putting a temp sensor on it…

Alright, one more layer of optimization. I’ve organized the top row of parts, which are 15v logic supply regulator related, into a better arrangement. Previously, they were extremely close together (soldering would have been difficult and hell if an IR lamp can reflow the pads in the dark alleyways of my L/C skyscrapers). I’ve space them apart alot more, but that involved moving the regulator chip itself down. This in turn meant I needed to shift some passives around. Whatever, the component density has only increased as a result.

(Now, none of this would be a problem if I would only use 0603 or 0402 SMT parts, but I’m too heavily invested in 1206 and fuck people with good eyesight.)

That is pretty much the final version of the board as it stands. With each of these revisions, I was sending it off to Advanced Circuit’s FreeDFM service in order to double check that it can actually be printed. I also ran a full Design Rule Check every time I changed a bunch of things between iterations. This was mostly me clicking “Approve” to all my vias-in-pads and insufficient solder mask clearances, but it did catch a few too-close-spacings.

Speaking of vias-in-pads, apparently they’re generally discouraged in automated PCB assembly, so in the interest of possibly getting this board professionally stuffed, I went through all the difficult tunneling in the gate drive and tried to un-pad my vias, at least connecting them to the pad with a short neck trace if possible.

This is a picture showing the VSS (everything-power-return) highlighted. Each gate drive now has its own private access to VSS at the location of the FET. This makes sure that 8 switching current pulses aren’t trying to octo-penetrate the thin logic regulator supply trace at the right in order to get back to the regulator. While it “worked” in RB version 1, it’s definitely not optimal. This general idea of not having signals mix with power is called Kelvin connecting, after the dude who first used it to sense very small voltages.

Highlighted now is the 15 volt distribution bus, which I’ve made strictly tree shaped this time. I try to adhere to the rule that any time power is being dealt with, closed loops are a bad idea.

The 5 volt bus follows a similar tree structure.

The large ground plane, which is the logic return path, is actually not a closed loop either. On the lower left corner, it was purposefully broken by judicious gate drive trace routing. It’s topologically a big mirrored C shape with the ends of the C right at the regulator output.

I’m pulling out all the stops I know to make sure that this board works on the first try. Ideally I’d get this sent to manufacturing through Myro tomorrow and have it ship right before Maker Faire 2012 in New York. This will probably be my on and off diddling project for most of the semester as a result. If it works out, I am now much less opposed to letting a few out “in the wild” for testing and subsequently investigating how much it would cost for Myro to just assemble all the parts, minus cables and through-hole pin headers and capacitors, for me.

To make it easier for them, I’ve placedallthe parts on the top side. That was the surprise – go back and look at the first few pictures now. Notice how all the parts are red (top layer)?

Now, all top side parts doesn’t instantly mean manufacturable. Once I build a few I might find where problem areas are. Say, anyone know if you can tell pick-and-place machines to put on the short and flat parts first?