• Musings on Tessel Two

    Monday, January 13, 2014

    1/13/2014— Eric Kolker

    As we wrap up the first wave of hardware design and push into production, we’ve turned our thoughts to what’s coming next. I’ll leave the discussion of the industry at large to the blogosphere, but continue the discussion Jon started about what comes next from Technical Machine, specifically on the hardware front.

    • Tessel 2 is an enormous opportunity space. We’ve tossed around the idea of
      • A simple update to the board, possibly baking some of the more common sensors (accelerometer/gyroscope, SD card, etc.) into the device
      • A smaller, low power version of the Tessel, probably with two module ports, a lower price point, more limited GPIO, and possibly a different wireless story (BLE, WiFi, cellular data of some kind, etc.). Just for kicks, here’s something we played around with (for the sake of R&D) a while back:
      • A ruggedized version of the board for our friends in industry, on boats, etc. who want to bake this into something highly reliable. We’re talking maybe as far as a waterproof case, dedicated battery, power in up to 48 V DC (AC wall power is a whole different animal), ethernet + POE support, etc.
      • Something for the roboticists out there… My guess is this would include a co-processor of some kind to handle control loops, high speed I/O, an IMU and communication with modern hobby radios. This kind of architecture is common in many robotic systems because pushing the robot’s “reflexes” down to a lower level processor frees up the main CPU to do computationally expensive mission planning while maintaining a more consistent system response to external forces. TLDR: deciding where to fly would take clock cycles away from subroutines that keep the quadcopter airborne if they shared the same CPU.
    • With a little help, many of our modules can be adapted to serve alternate functions. The best example is the Servo module, which can be converted into an LED driver (well, technically we convinced it to become a servo driver in the first place) or used to drive an external speed controller, thereby letting the Tessel control pretty much any kind of actuator you want. On a similar note, the NRF module can fake Bluetooth packets and the RFID module can also be used to transmit.
    • As an analog guy at heart, I’m itching to get some precision instrumentation out there, and a great opportunity just popped up with another project on Dragon Innovation. The Mooshimeter is a kick-ass multimeter that communicates over BLE and uses your phone as its display/controller. We’ll be working with their team to make sure that the Tessel can talk to the Mooshimeter, thereby opening up a whole slew of possibilities in the space of measuring hard to-reach electrical things (and normal-to-reach electrical things too). To give you a sense of the numbers here, the bare Tessel can measure voltage up to 3.3 V with 10 bits of resolution. The Mooshimeter would expand that to 600 V with 24 bits of resolution.
    • The next wave of modules will have to be better and more creative than ever. We’ve already covered most of the bases for “I/O you’d expect from something that talks to your phone,” which leaves, frankly, the more interesting things still on the table. Jon talked about the myoelectric sensor that Kelsey and I played with at Robots Conf, we’ve mentioned the possibility of an IMU and thermocouples, a more advanced camera, passive IR (motion detectors)…the list goes on. I’d love to see what people create with pressure and breakbeam sensors (think laser trip wire), magnetometers, and rangefinders. We’ve tossed around the idea of doing something with MIDI, too…
    • On a less physical level, I’d love to find new and improved ways for people to interact with and design hardware. I wrote a post a while back about my physical toolbox, but part of what I’ve come to appreciate in working on this project is just how far the software tools EEs use have to come. I’ve tried every once in a while to contribute to the growing effort, but there’s still a long way to go. Long story short, I believe that Technical Machine is in a good place to help with this movement.

    At the end of the day, what we do next depends a lot on what we hear from all of you. I’d love to build for the sake of building, and strive to keep my head up in the clouds, at least for a little while, but ultimately we can’t be successful if all we create are beutiful yet impractical tools. Let us know what you’re yearning for (team@technical.io), and we’ll do our best to keep up.

    Thanks!

    ~e

    #eric kolker #tessel #tessel 2 #technical machine #future directions #plans #modules

  • Delivery Schedule

    Friday, January 10, 2014

    1/10/2014— Updates

    A few weeks ago we gave an update that we had put 9 out of our 14 modules in production. Tessel is already in production at the moment, and is due to be done in February.

    We’ll be sending in the rest of the 5 modules into production at the end of this week/beginning of the next.

    Module manufacturing is delayed for a little over a week due to the upcoming Chinese New Year at the end of January (our modules are manufactured in China). This puts the delivery date from our manufacturer around mid-February for the 9 modules that we have already sent in.

    Depending on when we’re able to send in the rest of the 5 modules (audio, BLE, ambient, IR, and GPRS), the delivery date for our Dragon backers will be late February to early March. For pre-orders taken over our website (rather than crowdfunding), unless something unanticipated arises, we plan on shipping shortly thereafter.

    Once the modules are made, they will be shipped to our fulfillment partner Rush Order. Rush Order will begin shipping immediately as soon as they receive Tessels and modules.

    This is about two weeks later than we had originally anticipated shipping to Dragon backers: changed from mid-February to late February/early March. We underestimated how much of a delay Chinese New Year would have in our schedule, but we hope that this will be the last delay we run into.

    Oh, and here’s a picture of 1,500 unpopulated Tessel PCBs, sent to us this morning by our Tessel manufacturer Worthington Assembly:

    Cheers, and please reach out (team@technical.io) if you have any questions.

    Kelsey, Kevin, Jia, Jon, Eric, and Tim

    #tessel #technical machine #delivery #schedule #manufacturing #shipping schedule #backer update #update

  • Ideas for Next-Generation Tessels

    Wednesday, January 8, 2014

    1/8/2014— Jon McKay

    Every once in a while, after a long day of work, the Technical Machine team will sit down, grab a couple of beers (except Jia… or else she’ll fall asleep), and bounce ideas off of each other about aspirations for our future products.

    Most of our ideas are flat out ridiculous and will never come to fruition (I’m looking at you edible Tessel) but there are a handful of major underlying trends in the embedded space that we think could be important as a guiding principle for one of the next versions of our products.

    Robotics

    source: http://ghostradio.wordpress.com/tag/robotics/

    You’ve probably already heard all the news about Google scooping up Robotics companies left and right. And with good reason, too. Robots are expected to start generating huge amounts of valuable data within the next few years. But on top of that, they’re a ton of fun to build and play around with.

    In order to make a version of Tessel that’s ideal for robotics, would need to make some major changes including allowing for a beefier power supply up to 48V, more digital input and output pins, and a coprocessor with a realtime clock.

    Wearables & Biofeedback

    source: www.medgadget.com

    Wearables, are the obvious next step in making computers more mobile and closer to our senses. Some great examples of these kinds of projects are the MYO armband for controlling devices around you with your forearm muscles or Sensoria socks that improve your running style. Wearables can be more personalizable than other kinds of devices because they are so intimate with how your body works and what you physically spend your time doing. A wearable Tessel will need to be smaller, lower power (probably using BLE instead of WiFi) and maybe even flexible like a Limberboard.

    Biofeedback driven products are even closer to the senses and often overlap with wearables. My favorite example of this is this is the Emotiv headsets for gathering EEG data and controlling devices with your mind. There are a ton of other biofeedback sensors that could be used to gather data about the body. You can bet that once we finish making Tessel, I’ll be working on a node Emotiv library.

    Audio/Visual

    source: reviews.cnet.com

    If we’ve learned anything from the massive increase in photo and video production and consumption on mobile platforms, we know that there will be a huge demand for A/V technology on embedded devices. The camera module that we’re working on can only run between 10 and 15 frames per second so we’ll need much higher end camera hardware to get anything close to GoPro or Parrot Drone quality. To have a great user experience at higher resolutions we would need to make a pretty different version of Tessel with higher-bandwidth wireless transmissions, more on-board memory, and video codecs .

    We still have a lot of work to do on Tessel V1 but the time to start planning or even prototyping our next products start now. Are there any hardware directions you think we should go? Let us know! team@technical.io

    -Jon

    #jon mckay #tessel #technical machine #future #plans #upnext #startup

  • Designing the First Run Experience

    Friday, January 3, 2014

    1/3/2014— Kelsey Breseman

    I’m designing the first run experience for Tessel, and I want it to be excellent.

    It needs to do well with:

    Highly varied audience: Most of the people purchasing Tessel are used to writing code– but not all of them. This presents an immediate challenge: I don’t want to bore our main audience by including too many basics (“what’s the command line? How do I use it?”). People will skim, skip, roll their eyes, and probably miss important information.

    At the same time, I don’t want to alienate our beginning users; I’m all too familiar with technical sites that assume you have a lot more knowledge than you actually do, resulting in anger and frustration.

    Variation in product: Every user will have a Tessel and at least one module. That’s on purpose: we didn’t want people to get their Tessel, push the blinky example, then wonder what to do next. Instead, we want people to immediately plug in the modules they chose and try out their functionality. You’ll plug in your accelerometer module, wave it around, and see values changing on the screen. And then you’ll think, “What if I taped it to a ping-pong paddle?” “Can I use it to make my servo module move?” “How hard would it be to implement gesture control?”

    That’s all very good, but people have different modules or sets of modules, and it would be best if the instructions on the screen matched what you had in your hands. What’s more, the first run in my head ends with you on a page full of projects which use the modules you have.

    Other considerations: The first-run experience, first and foremost, needs to get a user from unboxing to up-and-running as seamlessly as possible– providing all necessary setup and orientation instructions. Users should also be introduced, via the first run experience, to the site’s project and community features, if these can be integrated into the setup.

    Here are some ideas on the subject:

    • Eric style, I could add in links every few sentences to (e.g.) a tutorial page for working with the command line.
    • Choose your own adventure: users select what modules they have, leading them on a customized first-run featuring their new abilities. This could also be extended to a customized-by-experience.
    • Adventure pre-chosen: since we have information on everyone’s orders, we could in theory give you a login or special key which would serve a first run tutorial based on your modules. This has the added benefit of logging you in to our site, which might make it easier to join the community.
    • Have login involving GitHub accounts. This would be useful generally, as we’d like to have GitHub integration with Tessel projects we’ll display on the site generally (more on that in another post perhaps; I’m also working on Tessel’s community aspects, including a way for the community to share their Tessel projects on the site). The other benefit of GitHub login could be to separate out experienced web programmers from people who might need a more detailed introduction to using node modules on Tessel– slyly serving up a customized first run.

    What would you like to see? Do you have any examples of particularly stellar first run experiences?

    Kelsey Breseman

    @SelkeyMoonbeam

    kelsey@technical.io

    #technical machine #tessel #kelsey breseman #community #github #first run experience #user experience

  • Testing Hardware

    Wednesday, January 1, 2014

    1/1/2014— Jia Huang

    In a few months we’ll be shipping over 1k Tessels and 4k modules. We want to make sure that every product we ship will work, so we shipped some test benches to our module manufacturer in China.

    These are the test benches for the RFID, Servo, Climate, nRF24, MicroSD, Camera, Relay, and GPS modules. Try and guess which are the ones we did closer to the deadline…

    The majority of the test benches are just Tessels. The Tessels can switch between multiple module tests so that our manufacturer can keep testing modules even if a few test benches break. For some modules we ended up using Arduinos since the C to JS firmware ports aren’t done yet.

    In all of the tests I tried to aim for the following:

    • Tests should cover core functionality
    • Tests should have clear instructions
    • Test benches should have minimal configuration

    Testing core functionality

    Each module test goes through a core use case (or multiple use cases), and tries to approximate how an end user would use the module.

    For example, our RFID module testbench has a 3 inch standoff with an RFID card taped to the top.

    If the module cannot detect from this distance, than the module has failed.

    Similarly, the nRF24 module goes through sending and receiving messages to another nRF24 module. The camera takes a picture and the test is to check whether or not the image is good.

    Clear instructions

    I tried to make the test benches as consistent and self explanatory as possible. All tests pass with either Green or Blue LEDs and fail on Red. Ideally, we would like these tests to be able to be run years from now if needed.

    I originally wrote the instructions in English, but then I realized that the tests are going to be run halfway across the world by workers whose primary language is Chinese. Most Chinese manufacturers have an English speaking rep or project manager, but the level of English proficiency varies pretty drastically. So I ended up translating the instructions to Chinese as well and having both on there.

    Minimal Configuration

    For some of our modules, it’s annoying to set up the test: the servo module can connect up to 16 different servos, and each servo takes 3 pins (ground, power, and signal). Testing all this by plugging in a servo into each position would take a long time. Relay testing takes a similarly long time since the tester needs to connect wires to the module.

    For these kinds of tests we made module testing PCBs designed to test all the pins at once. So instead of plugging in 16 different servos, the test can use just 1 Servo test PCB. This also has the added benefit of being able to see a clear pass/fail (is the LED on?) versus having to keep track of 16 servos.

    Coming in January

    We still have 5 more modules to get into manufacturing in early January: Ambient, IR, Bluetooth, GPRS, and Audio.

    Back to work.

    Jia

    #jia huang #test benches #testing #hardware #quality #tessel #technical machine #modules #hardware hacking

August 2018

January 2018

July 2017

February 2017

November 2016

October 2016

September 2016

August 2016

July 2016

June 2016

April 2016

March 2016

February 2016

November 2015

September 2015

August 2015

July 2015

June 2015

May 2015

March 2015

February 2015

January 2015

December 2014

November 2014

October 2014

September 2014

August 2014

July 2014

June 2014

May 2014

April 2014

March 2014

February 2014

January 2014

December 2013

November 2013

October 2013

September 2013

August 2013

July 2013