Mitochondrion glow staff progress – where I’m at, where I want to go

Back from Rainbow Serpent now and mostly recovered from having too much fun. So much fun that I haven’t any pics or vids. The Mitochondrion mark 4.2.3 got a great reception, someone described it as brain-melting, which is one of the feelings that I’m trying to create, and I got to meet lots of other good people and see lots of other LED gear.

I’ve mostly been developing this glow staff for my own pleasure* but with an eventual goal of making these available to other people. “Eventual” can be a long time in the future, but Reese from Soul-fire had a spin (and looked downright wonderfull with it) and then bounced up to me and said “you should be making these so other people can have this experience”. That’s the best reason for hurrying this process along.

Of course, that needs me to get over the desire to be constantly chasing after the the bleeding edge of what’s possible. That bleeding edge is charging off into the future with brighter and more numerous LEDs, fancier sensors, and smarter chips every year. The mark 4 is at the limit of hardware that was state of the art 18 months ago, so next step means new microcontroller family, LED strips, and battery chemistry. It means balancing the chase for the bleeding edge with three things that will make other people happier: reliability, affordability, and controllability.

Reliability: I broke the mark 4 again at Rainbow, dropped it two metres onto concrete while climbing on a huge lotus flower lounging structure. I knew which part had come loose and I fixed it in the back of the van with two wire-ties, but if someone is going to give me their money, then I don’t want to let them down. Equally, if a professional performer is using this for an act, I feel a responsibility to them, to their livelihood, and to their clients. And I feel a responsibility to the planet not to make more crap that gets thrown away after five minutes.

Over the past few years, I’ve tested versions, dropped them, found the weak spots, and learnt a good deal about how to make them durable. There’s still lots more to learn and it’s the kind of learning that only happens through real-world experience. For instance, I thought I could get away without cable clamps and just rely on the locking connectors not to pop out. With the small internal connectors I’m using, that’s not the case. Cable clamps are needed to take shock loads off the connectors, which is an easy fix but needs a longer circuit board with space for the clamps. That’s the kind of thing I want to know before accepting money from anyone.

Affordability: I used to be a rocket scientist, where it didn’t matter if it cost $100 million. Back in the real world, the cost of the Mark 4 is best described by a pained grimace. For parts alone, the current version looks something like:

  • Polycarbonate tube – $110
  • 3D printed end pieces – $180
  • 3D printed battery holders – $500 (if I wasn’t paying mates’ rates)
  • Arduino Nano microcontroller – $90
  • 20 NiMH rechargable batteries – $100
  • Addressable RGB LED strips – $50
  • Big voltage converter – $90
  • Little voltage converter – $10
  • Tantalum capacitors for little voltage converter, ethically sourced – $60
  • 9-way motion sensor – $110
  • Microphone, op-amp and audio analyser chip – $25
  • Custom PCB – $50
  • Screws, aluminium spine, sockets, connectors, resistors, caps, stand-offs, spacers, and sellotape – $haven’t counted

That’s well over a grand on parts alone (and forgetting labour, writing off development costs and ignoring costs from marketing, selling, and maintaining). Some of that is necessary cost, but much of it isn’t. Thus there’s lots of cost engineering to do. There’s three approachers for that. The first is design for manufacture. For instance, failing to sleep while back in Melbourne lead to a much cheaper design for the battery holders, like fifty times cheaper. Secondly, I can buy cheaper parts, if they will be reliable. I can get a copy of the microcontroller board for $15, but I’ve had 50% failure rates on the cheap ones and 0% on the expensive ones. So sod that. Thirdly, I can ask “is this functionality worth the money?” The audio sensor costs $25 and generating patterns in response to music will look pretty good. The motion sensor costs $100+ and generating patterns in response to movement will look pretty good. Will it look four times as good?

Controllability: Right now, the mark 4 just splatters a bunch of patterns onto the retinas of anyone nearby. When it starts spinning, it wakes up and goes nuts, when it stops spinning then it drops into one of the ambient modes, and then after a while it goes back to sleep. That’s cool, but it could be much more responsive to what is happening around it, how someone is using it, and what they are telling it to do. I’ve a lot of ideas about how to do all of those things, synching it to music, having it gesture-controlled, and wirelessly controlled from a phone. For performances, you’re going to want to set a sequence of patterns and trigger points. The hardware for all of this is in place, it’s just a question of writing the software and seeing what works in reality.

This year’s plan: So then, here’s what I’d like to do this year:
1) Use the existing mark 4 as a development platform for writing the code for sound-, motion-, and gesture-responsive behaviour.
2) Calve off the pattern generator code as a stand-alone library, so that anyone with an Arduino and an LED strip can use it to bring the shiny. This isn’t on the critical path, but I’ve had so much help from the Arduino community that I want to give something back.
3) Build the mark 5 with a view to a more saleable product. Current plans for the hardware are a gruntier microcontroller (probably an ARM Cortex), lithium batteries, the Neopixel LED strips (80 LEDs not 44, and four strips not two), and a new internal structure to hold all of this. I want something that reuses the mark 4 code, does more, costs less, and doesn’t break.

Hmm, maybe that’s the plan for the next two years. But at the end of those three steps, I want something I can give to other people, for them to test, for them to use and break in ways that I would never manage myself. I want something where I can share the learning process and then after that, I want something I can sell.

Oh, and I went to a very inspiring workshop on staff dance run by Wolf. I can just spin the thing in front of me, to create a worm-hole in reality for my brain to fall into, but there’s so much more possiblity in moving with the staff. So I want to completely change my style, into one that’s much less spinning and more dance and aikido.

For once in my life, I’ve got time. The house is built and finished, at least to the point where I don’t feel the need to work on it every evening and weekend. The day job remains enjoyable and makes me feel that I’m contributing to creating a better world, but at the end of eight hours, I can go and work on my own plans. I have the usual variety of other projects but none that I’m taking as seriously as the Mitochondrion. And now that my wrist is mostly fixed, I’ll be training aerials and getting back to aikido, but the time and energy that requires is returned over and again as a clearer and more productive brain results from a healthier body. So, bring on this year. It’s going to be fun.

* – And carrying something visible from a kilometre away helps my friends to find me in the dark at festivals. Admittedly, One of the good people I met at Rainbow was Gem. He makes pretty cool LED toys for his friends, with the reason that he wants to be able to find his friends at festivals. So yeah, that made me realise that I’m a tad self-centred. Rainbow was good for realisations.

33 Responses to 'Mitochondrion glow staff progress – where I’m at, where I want to go'

  1. randomdreams says:

    I do not remember what happened to your wrist?

  2. randomdreams says:

    I do not remember what happened to your wrist?

  3. randomdreams says:

    I do not remember what happened to your wrist?

  4. pinkiepoopoo says:

    the lawn mower survived until the final night of kiwiburn, when the under-body blue lights failed partly through the stress of being pushed at speed over rough grass… and partly through it being stored inside the van in an awkward position and dislodged.

    but then again, the damaged lights are a string of blue LEDs that came attached to a two-AA-battery switchbox and obtained from the warehouse for $5 several year ago. not surprisingly several of them are ripped off it.

    the remediation exercise will involve the use of another string of them that I have lying around, and this time instead of stapled to the edges of the sub they will be inserted into a length of plastic tubing attached to the perimeter of the blade housing.

    doof doof…

  5. pinkiepoopoo says:

    the lawn mower survived until the final night of kiwiburn, when the under-body blue lights failed partly through the stress of being pushed at speed over rough grass… and partly through it being stored inside the van in an awkward position and dislodged.

    but then again, the damaged lights are a string of blue LEDs that came attached to a two-AA-battery switchbox and obtained from the warehouse for $5 several year ago. not surprisingly several of them are ripped off it.

    the remediation exercise will involve the use of another string of them that I have lying around, and this time instead of stapled to the edges of the sub they will be inserted into a length of plastic tubing attached to the perimeter of the blade housing.

    doof doof…

  6. pinkiepoopoo says:

    the lawn mower survived until the final night of kiwiburn, when the under-body blue lights failed partly through the stress of being pushed at speed over rough grass… and partly through it being stored inside the van in an awkward position and dislodged.

    but then again, the damaged lights are a string of blue LEDs that came attached to a two-AA-battery switchbox and obtained from the warehouse for $5 several year ago. not surprisingly several of them are ripped off it.

    the remediation exercise will involve the use of another string of them that I have lying around, and this time instead of stapled to the edges of the sub they will be inserted into a length of plastic tubing attached to the perimeter of the blade housing.

    doof doof…

  7. edm says:

    A couple of things which may help/be of interest on the “making more than just a prototype” front:

    1. There are “more efficient than Arduino” runtime environments for the AVR chips, of which (based on talks at LCA), MHVLib looks to be one of the more promising. (Slides from earlier talk; I can’t easily find the slides from the talk at LCA at present, but in theory there will also be a video later.) Robert Mibus’s “After Arduino” talk at LCA may also be relevant (github account). Both offer the option of saving a couple of KB (at least) from the Arduino overhead.

    2. On the manufacturing front, Bunnie’s keynote talk at LCA (Thursday morning) would be worth seeing when the video comes out. (someone’s notes; I can’t find slides online.) He also has a series of articles on manufacturing for hardware startups: parts 1, 2, 3, 4.

    And Jonathan Oxer (the guy who runs Freetronics) is also a good contact — as Pia and I have both mentioned before. He’s done a bunch of manufacturing of Ardinuo-related things in China in “short run” sort of scale (where “short run” is under 10k units….). His Ardusat talk would be worth seeing when the video comes out, particularly for observations about lowering cost of manufacture. (He’s done a bunch of Arduino-related hardware design for the Ardusat. The talk slides were mostly pictures, so the “good stuff” is in the audio.)

    Even for short runs it’s possible to lower the cost dramatically from 3D-printed-individually prices. Especially if you’re willing to deal with not-especially-beautiful plastics injection for instance (eg, parts that are hidden).

    Ewen

    • admin says:

      1) There’s “more efficient” and then there’s twice the SRAM. I’m not exceeding the 32 kB on the Arduino’s ATmega328 by a smidgen, I’m currently looking at about 45 kB without all of the bells and whistles. An ARM Cortex gets me 64 to 256 kB SRAM so I can stop worrying about code size (and 32 bit processing for faster execution).

      2) Yup, Bunnie’s four-parter today is useful stuff. Read it this morning. I’ll have a look at the other talks, but seriously, can people provide transcripts? I read faster than people talk by a factor of lots.

      3) Yes, injection moulding is cheaper than 3D printing, if and only if you are 3D printing shapes that can be injection moulded. But if you’re doing that, then you’re not using 3D printing the right way. The key for me is that 3D printing lets you combine multiple functionality into a single piece while making that piece cheaper. Some of the existing end-cap parts have cavities to hole two sockets, more cavities to pass cables through, have round holes for screws and hexagonal holes to hold the nuts that the screws fit into, have rectangular slots to locate the spines, and holes to fix the spines. Each of these features adds utility and decreases the cost of the part. Yes, I could redesign each part to be injection mouldable, but then this one part would be (about) four parts and each hole or feature on each part will cost more, not less.

      • edm says:

        I suspect the main reason that more talks don’t get transcripts (and I agree, I like transcripts too) is that it’s a lot of work to prepare them well, for limited (apparent) return. The “live blogging” psuedo-transcripts that people write while listening in the talk tend to be the closest it gets for many talks. (My solution to long “low bandwidth” talks is to listen to them while doing something else. It’s still not optimal, but at least it doesn’t feel like quite as hopeless dead time.)

        On the injection moulding front I was particularly thinking of the battery holders, which seemed to be “half” of your BOM (as listed in your post) — and seem like they ought to be something that could be injection moulded in 1 or 2 parts each. But perhaps your Melbourne-redesign achieves a similar cost reduction, and avoids the one-off cost of tooling. The end caps would perhaps be a less obvious win for injection moulding, given your description. Although it might be that moulding + drilling would get pretty close.

        On the CPU front it’s not clear to me what you’re doing that requires such a large RAM budget. But I agree that being 50% over budget on RAM isn’t something that is going to be fixed just by a more efficient library. (I’d be wondering whether anything could be smaller data types and/or was in fact ROMable but hadn’t been marked as such. IIRC you’re already short on CPU cycles too, so recalculating things at runtime is probably a non-starter.)

        FWIW, I think you’d probably be able to sell a reasonable number if you could get the retail cost down under NZ$300. (Probably NZ$300 plus “buy your own NiMH batteries” in practice, given that’s a non-trivial cost in itself.)

        Ewen

        • admin says:

          The Melbourne redesign for the battery holders should replace two $250 parts with six complicated but small $10 parts. When you’re getting to that level and you’re after less than 10k parts, I think 3D printing is the solution.

          As for the RAM, sorry, but I was getting SRAM & PROGMEM mixed up. I’m expecting to need about 45 kB PROGMEM. Even so, the SRAM usage currently looks like:

          • 2 pattern generators, each holding a byte per LED for each of hue, saturation, & brightness;
        • 2 output buffers, each holding a byte per LED for red, green, & blue;

          (The two output buffers flip/flop, so that the last output is still around to let it do time-filtered patterns.)

          So that’s forty-four bytes times twelve already, before we get any other variables, objects, look-up tables, or sensor buffers. In 2 kB SRAM.

          I’d like to run more than two concurrent pattern generators, but if each one takes $numLEDs x 3 then ooo… But I really only need one pattern generator to be active across the whole length of the staff to do backgrounds, the rest can hold smaller textures that are moved to where they are needed – hey, I’ve just invented sprites!

  • edm says:

    People keep inventing sprites, for they are a very useful concept 🙂 (One of the talks I went to earlier this week described how people had invented using fonts, with custom glyph definitions, as a means of sprites on modern web pages. Which is something I remember being done in the 1980s…)

    FWIW, most embedded devices end up having “rough approximation of desired calculations” values/algorithms/etc in them. Particularly when things are in motion/short lasting, so that any inaccuracies were soon replaced by something else. For your pattern generators I’m wondering if delta compression, and packing into one byte (eg, 2-bit hue change, 2-bit saturation change, 4-bit brightness change) would help. And perhaps whether you could get away with, say, 5-bit red, 5-bit blue and 6-bit green (eye’s are more receptive to green). (It wouldn’t be _as_ good, but such are the ways of manufacturing cost reduction…)

    Ewen

  • edm says:

    People keep inventing sprites, for they are a very useful concept 🙂 (One of the talks I went to earlier this week described how people had invented using fonts, with custom glyph definitions, as a means of sprites on modern web pages. Which is something I remember being done in the 1980s…)

    FWIW, most embedded devices end up having “rough approximation of desired calculations” values/algorithms/etc in them. Particularly when things are in motion/short lasting, so that any inaccuracies were soon replaced by something else. For your pattern generators I’m wondering if delta compression, and packing into one byte (eg, 2-bit hue change, 2-bit saturation change, 4-bit brightness change) would help. And perhaps whether you could get away with, say, 5-bit red, 5-bit blue and 6-bit green (eye’s are more receptive to green). (It wouldn’t be _as_ good, but such are the ways of manufacturing cost reduction…)

    Ewen

  • edm says:

    People keep inventing sprites, for they are a very useful concept 🙂 (One of the talks I went to earlier this week described how people had invented using fonts, with custom glyph definitions, as a means of sprites on modern web pages. Which is something I remember being done in the 1980s…)

    FWIW, most embedded devices end up having “rough approximation of desired calculations” values/algorithms/etc in them. Particularly when things are in motion/short lasting, so that any inaccuracies were soon replaced by something else. For your pattern generators I’m wondering if delta compression, and packing into one byte (eg, 2-bit hue change, 2-bit saturation change, 4-bit brightness change) would help. And perhaps whether you could get away with, say, 5-bit red, 5-bit blue and 6-bit green (eye’s are more receptive to green). (It wouldn’t be _as_ good, but such are the ways of manufacturing cost reduction…)

    Ewen

  • admin says:

    The Melbourne redesign for the battery holders should replace two $250 parts with six complicated but small $10 parts. When you’re getting to that level and you’re after less than 10k parts, I think 3D printing is the solution.

    As for the RAM, sorry, but I was getting SRAM & PROGMEM mixed up. I’m expecting to need about 45 kB PROGMEM. Even so, the SRAM usage currently looks like:

    • 2 pattern generators, each holding a byte per LED for each of hue, saturation, & brightness;
  • 2 output buffers, each holding a byte per LED for red, green, & blue;

    (The two output buffers flip/flop, so that the last output is still around to let it do time-filtered patterns.)

    So that’s forty-four bytes times twelve already, before we get any other variables, objects, look-up tables, or sensor buffers. In 2 kB SRAM.

    I’d like to run more than two concurrent pattern generators, but if each one takes $numLEDs x 3 then ooo… But I really only need one pattern generator to be active across the whole length of the staff to do backgrounds, the rest can hold smaller textures that are moved to where they are needed – hey, I’ve just invented sprites!

  • admin says:

    The Melbourne redesign for the battery holders should replace two $250 parts with six complicated but small $10 parts. When you’re getting to that level and you’re after less than 10k parts, I think 3D printing is the solution.

    As for the RAM, sorry, but I was getting SRAM & PROGMEM mixed up. I’m expecting to need about 45 kB PROGMEM. Even so, the SRAM usage currently looks like:

    • 2 pattern generators, each holding a byte per LED for each of hue, saturation, & brightness;
  • 2 output buffers, each holding a byte per LED for red, green, & blue;

    (The two output buffers flip/flop, so that the last output is still around to let it do time-filtered patterns.)

    So that’s forty-four bytes times twelve already, before we get any other variables, objects, look-up tables, or sensor buffers. In 2 kB SRAM.

    I’d like to run more than two concurrent pattern generators, but if each one takes $numLEDs x 3 then ooo… But I really only need one pattern generator to be active across the whole length of the staff to do backgrounds, the rest can hold smaller textures that are moved to where they are needed – hey, I’ve just invented sprites!

  • edm says:

    I suspect the main reason that more talks don’t get transcripts (and I agree, I like transcripts too) is that it’s a lot of work to prepare them well, for limited (apparent) return. The “live blogging” psuedo-transcripts that people write while listening in the talk tend to be the closest it gets for many talks. (My solution to long “low bandwidth” talks is to listen to them while doing something else. It’s still not optimal, but at least it doesn’t feel like quite as hopeless dead time.)

    On the injection moulding front I was particularly thinking of the battery holders, which seemed to be “half” of your BOM (as listed in your post) — and seem like they ought to be something that could be injection moulded in 1 or 2 parts each. But perhaps your Melbourne-redesign achieves a similar cost reduction, and avoids the one-off cost of tooling. The end caps would perhaps be a less obvious win for injection moulding, given your description. Although it might be that moulding + drilling would get pretty close.

    On the CPU front it’s not clear to me what you’re doing that requires such a large RAM budget. But I agree that being 50% over budget on RAM isn’t something that is going to be fixed just by a more efficient library. (I’d be wondering whether anything could be smaller data types and/or was in fact ROMable but hadn’t been marked as such. IIRC you’re already short on CPU cycles too, so recalculating things at runtime is probably a non-starter.)

    FWIW, I think you’d probably be able to sell a reasonable number if you could get the retail cost down under NZ$300. (Probably NZ$300 plus “buy your own NiMH batteries” in practice, given that’s a non-trivial cost in itself.)

    Ewen

  • edm says:

    I suspect the main reason that more talks don’t get transcripts (and I agree, I like transcripts too) is that it’s a lot of work to prepare them well, for limited (apparent) return. The “live blogging” psuedo-transcripts that people write while listening in the talk tend to be the closest it gets for many talks. (My solution to long “low bandwidth” talks is to listen to them while doing something else. It’s still not optimal, but at least it doesn’t feel like quite as hopeless dead time.)

    On the injection moulding front I was particularly thinking of the battery holders, which seemed to be “half” of your BOM (as listed in your post) — and seem like they ought to be something that could be injection moulded in 1 or 2 parts each. But perhaps your Melbourne-redesign achieves a similar cost reduction, and avoids the one-off cost of tooling. The end caps would perhaps be a less obvious win for injection moulding, given your description. Although it might be that moulding + drilling would get pretty close.

    On the CPU front it’s not clear to me what you’re doing that requires such a large RAM budget. But I agree that being 50% over budget on RAM isn’t something that is going to be fixed just by a more efficient library. (I’d be wondering whether anything could be smaller data types and/or was in fact ROMable but hadn’t been marked as such. IIRC you’re already short on CPU cycles too, so recalculating things at runtime is probably a non-starter.)

    FWIW, I think you’d probably be able to sell a reasonable number if you could get the retail cost down under NZ$300. (Probably NZ$300 plus “buy your own NiMH batteries” in practice, given that’s a non-trivial cost in itself.)

    Ewen

  • admin says:

    1) There’s “more efficient” and then there’s twice the SRAM. I’m not exceeding the 32 kB on the Arduino’s ATmega328 by a smidgen, I’m currently looking at about 45 kB without all of the bells and whistles. An ARM Cortex gets me 64 to 256 kB SRAM so I can stop worrying about code size (and 32 bit processing for faster execution).

    2) Yup, Bunnie’s four-parter today is useful stuff. Read it this morning. I’ll have a look at the other talks, but seriously, can people provide transcripts? I read faster than people talk by a factor of lots.

    3) Yes, injection moulding is cheaper than 3D printing, if and only if you are 3D printing shapes that can be injection moulded. But if you’re doing that, then you’re not using 3D printing the right way. The key for me is that 3D printing lets you combine multiple functionality into a single piece while making that piece cheaper. Some of the existing end-cap parts have cavities to hole two sockets, more cavities to pass cables through, have round holes for screws and hexagonal holes to hold the nuts that the screws fit into, have rectangular slots to locate the spines, and holes to fix the spines. Each of these features adds utility and decreases the cost of the part. Yes, I could redesign each part to be injection mouldable, but then this one part would be (about) four parts and each hole or feature on each part will cost more, not less.

  • admin says:

    1) There’s “more efficient” and then there’s twice the SRAM. I’m not exceeding the 32 kB on the Arduino’s ATmega328 by a smidgen, I’m currently looking at about 45 kB without all of the bells and whistles. An ARM Cortex gets me 64 to 256 kB SRAM so I can stop worrying about code size (and 32 bit processing for faster execution).

    2) Yup, Bunnie’s four-parter today is useful stuff. Read it this morning. I’ll have a look at the other talks, but seriously, can people provide transcripts? I read faster than people talk by a factor of lots.

    3) Yes, injection moulding is cheaper than 3D printing, if and only if you are 3D printing shapes that can be injection moulded. But if you’re doing that, then you’re not using 3D printing the right way. The key for me is that 3D printing lets you combine multiple functionality into a single piece while making that piece cheaper. Some of the existing end-cap parts have cavities to hole two sockets, more cavities to pass cables through, have round holes for screws and hexagonal holes to hold the nuts that the screws fit into, have rectangular slots to locate the spines, and holes to fix the spines. Each of these features adds utility and decreases the cost of the part. Yes, I could redesign each part to be injection mouldable, but then this one part would be (about) four parts and each hole or feature on each part will cost more, not less.

  • edm says:

    FYI, Bunnie’s Talk (MP4) (there’s an OGV nearby too), the After Arduino (MP4) talk, and Jonathan Oxer’s Ardusat (MP4) talk. It appears they haven’t yet got to processing the miniconfs (first two days) so I can’t see a video of the MHVLib talk yet.

    Ewen

  • edm says:

    FYI, Bunnie’s Talk (MP4) (there’s an OGV nearby too), the After Arduino (MP4) talk, and Jonathan Oxer’s Ardusat (MP4) talk. It appears they haven’t yet got to processing the miniconfs (first two days) so I can’t see a video of the MHVLib talk yet.

    Ewen

  • edm says:

    FYI, Bunnie’s Talk (MP4) (there’s an OGV nearby too), the After Arduino (MP4) talk, and Jonathan Oxer’s Ardusat (MP4) talk. It appears they haven’t yet got to processing the miniconfs (first two days) so I can’t see a video of the MHVLib talk yet.

    Ewen

  • edm says:

    A couple of things which may help/be of interest on the “making more than just a prototype” front:

    1. There are “more efficient than Arduino” runtime environments for the AVR chips, of which (based on talks at LCA), MHVLib looks to be one of the more promising. (Slides from earlier talk; I can’t easily find the slides from the talk at LCA at present, but in theory there will also be a video later.) Robert Mibus’s “After Arduino” talk at LCA may also be relevant (github account). Both offer the option of saving a couple of KB (at least) from the Arduino overhead.

    2. On the manufacturing front, Bunnie’s keynote talk at LCA (Thursday morning) would be worth seeing when the video comes out. (someone’s notes; I can’t find slides online.) He also has a series of articles on manufacturing for hardware startups: parts 1, 2, 3, 4.

    And Jonathan Oxer (the guy who runs Freetronics) is also a good contact — as Pia and I have both mentioned before. He’s done a bunch of manufacturing of Ardinuo-related things in China in “short run” sort of scale (where “short run” is under 10k units….). His Ardusat talk would be worth seeing when the video comes out, particularly for observations about lowering cost of manufacture. (He’s done a bunch of Arduino-related hardware design for the Ardusat. The talk slides were mostly pictures, so the “good stuff” is in the audio.)

    Even for short runs it’s possible to lower the cost dramatically from 3D-printed-individually prices. Especially if you’re willing to deal with not-especially-beautiful plastics injection for instance (eg, parts that are hidden).

    Ewen

  • edm says:

    A couple of things which may help/be of interest on the “making more than just a prototype” front:

    1. There are “more efficient than Arduino” runtime environments for the AVR chips, of which (based on talks at LCA), MHVLib looks to be one of the more promising. (Slides from earlier talk; I can’t easily find the slides from the talk at LCA at present, but in theory there will also be a video later.) Robert Mibus’s “After Arduino” talk at LCA may also be relevant (github account). Both offer the option of saving a couple of KB (at least) from the Arduino overhead.

    2. On the manufacturing front, Bunnie’s keynote talk at LCA (Thursday morning) would be worth seeing when the video comes out. (someone’s notes; I can’t find slides online.) He also has a series of articles on manufacturing for hardware startups: parts 1, 2, 3, 4.

    And Jonathan Oxer (the guy who runs Freetronics) is also a good contact — as Pia and I have both mentioned before. He’s done a bunch of manufacturing of Ardinuo-related things in China in “short run” sort of scale (where “short run” is under 10k units….). His Ardusat talk would be worth seeing when the video comes out, particularly for observations about lowering cost of manufacture. (He’s done a bunch of Arduino-related hardware design for the Ardusat. The talk slides were mostly pictures, so the “good stuff” is in the audio.)

    Even for short runs it’s possible to lower the cost dramatically from 3D-printed-individually prices. Especially if you’re willing to deal with not-especially-beautiful plastics injection for instance (eg, parts that are hidden).

    Ewen

  • Leave a Reply

    Your email address will not be published. Required fields are marked *

    *