Thoughts on the Tessel Project vision

[Frijol]

This issue is to solicit community thoughts on the long-term vision of the Tessel Project. In particular, we're looking for reactions to and comments on the vision outlined here: https://tessel.io/blog/147467781587/where-are-we-going-with-tessel-rust-reach-and

What we're looking for

• Suggestions of technology
• Discussion of use cases you would like to solve, and whether the ideas we have are good fits for your use cases
• Experiences you've had with the technologies or similar projects
• A good discussion from many perspectives

What we're not looking for

• Consensus – ultimately, the Steering Committee will make a call on the vision. This issue is to advise that discussion
• Fighting/technology fundamentalism. Goes without saying, but I'm saying it anyway. Be constructive and be good to each other!

Logistics

This issue will be open for comments until August 31. After that, we'll close the issue.

Comments welcome from all members of the community! Even if you think your use case is small, we would love to hear from you.

[ootoovak]

It was really great to read where the Tessel Steering Committee (TSC) wants to take things so thank you for sharing. I am really happy to hear about the TSC is wanting to focus on first class support for Rust on Tessel. Rust support is one of the reasons I decided to buy Tessel 2 in the first place, to gain more experience with system level programming languages and hardware. 😄 👍

[boneskull]

Hi, saw the call for comments. Apologize for rambling But editing a textarea sucks on a phone.

• I'm concerned pledging "first-class" support for two languages will spread the team too thin.

  OTOH, I can't see how a production device running JavaScript--real, honest-to-god JavaScript--could ever justify itself due to the cost and inefficiencies.

  Go a step further, and say that even one that isn't running but still could run JS is inefficient as well.

• I missed where JS compiles to Rust... Confused on that point.

• I never had a use for official modules and don't understand where they fit into the proposed grand plan. How does "Reach" improve on this?

• I like Tessel 2. I like running my J5 code on the board itself. But it's weird. You know? Like why not go RPi or CHIP if you're going to run Linux anyway and plug the thing in?

• For me the holy grail is "run performant, low-power node.js on a $5 board. With wifi, USB and gpio" I'll take 10 of them to put around my house. But probably not going to build a device around it and sell it.

OSHW should be a platform for serious product development, not only a sharing marketplace for makers.

The only thing I really get about OSHW is that it allows me to buy dirt-cheap arduino clones.

I can't print a decent pcb at home. I can't use KiCad. Or eagle. Or solder tiny surface-mount components. Even if I could do all these things, how would I send a PR to the schematic? Would it get merged and go out with the next production run? but the bug would still be in my old production board, and everyone else's too.

I have a feeling I'm not alone here. It doesn't feel like OSHW is "for" people like me.

So I'd like to flash board X with Tessel's firmware and use the cli with it. Maybe the future of Tessel isn't hardware, but tooling. Wasn't the point of running JS on a board to be friendlier to software devs...? Anyway, that's my bright idea. 😄

[anujdeshpande]

I came here to 👍 the idea of making it easy for people to go from their prototype to production. There is a very solid wall between your Arduino/RPi prototypes and the finished product that you buy off a shelf. There should be more efforts like this.
I know BeagleBoard is doing this : Autodesk created a printer using their OSHW designs, Octava systems has come up with a SoM to make it even more easier.

It would be super-awesome to see a product based off Tessel !

@boneskull : There have been instances of smaller changes taking place in between 2 productions runs for the same version of a board. I remember they changed the resistance values for the LED on the BeagleBone Black because people thought it was too bright. So a PR for a schematic is definitely possible. Having said that, you are right. It's not going to fix your old board and it's not going to be possible for a lot of the major stuff.
But then again the point is making people make products. OSHPark, DirtyPCBs, etc are making it super cheap to make custom boards. Perhaps the Tessel folks can up with a SoM in the near future where people can just use that for going to prod with their Tessel 2 protos.

Another suggestion to Tessel is that it would be great to see some stuff for security. Secure boot, JTAG locking, etc from a 'creating a product' point of view.

Cheers !

(PS: I am doing a WiFi microcontroller board called Knit based on the same chip as Kinoma Element. Been a fan of Tessel ever since I tried it out at IoT@Scale, SAP)

[boneskull]

Please understand I'm not trying to knock Tessel or the effort behind it. I love working with dev boards AND JavaScript. Tessel makes that possible. I should buy more.

Just worried with the new direction(s), Tessel is trying to be everything to everybody. Please refute 😄

[Frijol]

Thanks all who have contributed to the conversation so far!

A few thoughts on ideas so far expressed (note: I speak for my perspective, not necessarily the perspective of the whole SC here):

Tessel is trying to be everything to everybody

We're explicitly trying to support this production path above e.g. hobbyists and makers. Nothing against hobbyists and makers, but I think these communities are well supported by various communities, even to the extent that they can be successful on our platform without us as an org expending much effort into that sphere.

In practice, this might not appear to be the case. By virtue of the Tessel Project being this somewhat amorphous community of individuals, there will be active community members who spend all their time on hobby things and supporting fellow makers. This is great. Everyone is welcome, and we're happy to see this. But "core work" is more focused along the lines of the outlined vision.

@boneskull this touches on your "OSHW is not for people like me" comment. In some ways, you're right. Maybe you don't want to make your own PCBs, and therefore you don't care if we use KiCAD vs. DipTrace. But per "openness creates innovation", I firmly believe that we (as a global hardware community) will have a bigger ecosystem of hardware choices if it becomes easier for people who do want to make their own PCBs to do so. And those hardware choices might be for you.

Rust + JS as both first-class supported languages will spread us too thin

This is a valid concern, but I sincerely hope not! Part of the reason we're excited to work in Rust is because we hope this will bring in new contributors and thus expand our abilities to accomplish more.

Rust is a new language, and it's not been strongly affiliated with particular hardware yet. This makes the Rust community excited about Tessel. In practice, we've already see a few new (and steady) contributors join the project in order to work on Rust support. Might be some confirmation bias, but I think this is promising.

It is my hope that Rust contributors will value the platform as a whole and continue to contribute towards it into the future.

Further, maintaining first-class support for JS is not so difficult as it was on, say, Tessel 1. We don't have to keep up with changes to native libraries; at a certain point, we just have to upgrade the version of Node the Tessel is using and make sure the CLI still works with LTS releases. Seems doable.

I never had a use for official modules and don't understand where they fit into the proposed grand plan. How does "Reach" improve on this?

Reach would have a module port, breaking out 10 pins just as it does on the board. GPIO, SPI, I2C, and UART.

The "official" modules are valuable to people who aren't comfortable with/interested in soldering or plugging in wires. They also make for a nice, clean form factor as long as they suit your purpose. But if you don't care about these things, the breakout of all the major communication protocols, power, and ground in a standardized format should still be valuable to you.

@boneskull how have you used Tessel + module ports thus far?

For me the holy grail is "run performant, low-power node.js on a $5 board. With wifi, USB and gpio"

A holy grail indeed! Lots of people want this, but it's not something anyone has figured out how to make yet. Wifi is generally high-power. Node.js has limitations re performance. USB headers alone add cost to the board price. Technical and cost trade-offs all around.

This use case is essentially the point of Reach: program in Node on Tessel 2, which directs several Reach boards with lower-level commands; have your cheap, performant, low power, GPIO Reach boards all over your house; have them be able to talk back up to the internet via a Tessel 2's wifi.

Rust support is one of the reasons I decided to buy Tessel 2 in the first place, to gain more experience with system level programming languages and hardware.

@ootoovak and anyone else who feels this way: we're happy to have you! Please feel welcome on the #rust-lang channel of the Tessel Slack - whether just to try what we have so far, to contribute, or to get a project to learn on.

Rust is new enough that we have a pretty wide diversity of experiences working on this project - including my own Rust beginner status.

Perhaps the Tessel folks can up with a SoM in the near future where people can just use that for going to prod with their Tessel 2 protos.

@anujdeshpande what does SoM stand for here?

Thanks again, all, for your thoughts!

[anujdeshpande]

@Frijol SoM stands for system on module - you take 4-5 different components that you are going to need to build a working system (processor, flash, power management IC, WiFi, must-have passives) and make a single machine assemblable component out of it. That way people can just use that instead of procuring all the things separately. Octavo

[reconbot]

@anujdeshpande I really really like that we have nodejs. Having recently evaluated the Kinoma Element I can say that while the device is ok for the most part, it's very difficult to use any of the existing javascript libraries and you'll be writing anything you write for that from scratch. The cost is low only if your time is free.

@boneskull having tried to get people started on the Edison, the RPI, and the CHIP, the need to manage a full linux environment has been a major impediment. (don't get me started on sysfs) I've seen platforms like Resin.io make that a lot easier. Resin provides a cloud managed docker containers for single board computers. ("Cloud" being another impediment tbh.) But there's currently no fully open source competitor to the tessel 2 in a managed linux single board computer. You give us your app and we run it for you. I haven't seen any other platform give that level of service.

It's why we chose to work with Tessel for the J5IK.

@Frijol I'd love to see a clear path to production too but I don't think we're in a great place to do that. And I think it will take a lot of work to get there.

It would pay to do user interviews if production is our goal. Through my work at bocoup I've learned that there's a lot of different weird things people expect of hardware in production. What we choose can only be a subset of that, building blocks.

This list is going to range from low level services to application level concerns. Tessel doesn't need to have an answer to all of them but they are all things I think are missing from an open source IoT platform.

Device Management

• The tools that make it a joy to prototype don't scale to a fleet of devices. The needs of a fleet of Tessels aren't yet defined but we haven't really focused on anything beyond one developer and one device.
• Wifi configuration for non developers. A mobile app or hotspot based config to make this easy would go a long way. [Proposal] Network API changes t2-firmware#198
• An application watchdog to restart the device when apps fail due to memory leaks or if they stop responding.
• A way to do remote firmware upgrades and/or fallbacks (or local upgrades without a computer running t2-cli)
• A way to monitor and manage a fleet of devices running the same app
• A way to collect logs outside of the device
• A way to communicate to a device behind a NAT

Beyond the device management layer there's common app requirements where there is no current open source solution. Google and many others are trying to fill this niche and it's.. scary.

App level concerns

• Identity and Access management. A way to provision a device and associate it with a remote account. "Make this device mine"
• Some sort of security model. Local WiFi gets full control only goes so far. and "give this phone access to this device"
• Data or event logging

Hardware Concerns

• We have a weird form factor
• We have unknown power requirements
• We're a little expensive for the memory and processing power we provide and it's hard to source the hardware
• Sleep mode, is this possible with our hardware? Yes it is. [Proposal] Sleep ability t2-firmware#199

I want to close with taking a moment, to say I didn't enumerate all the awesome things our platform does. (Of which there are many.)

[reconbot]

Oh and I forgot!

The Reach, I'd love to see it be generic bluetooth, so we could provide a USB bluetooth dongle for the t2, and any linux based single board computer could use the tessel reach hardware to communicate. If we use the 10 pin breakout I fear we'll have a much smaller adoption.

[rwaldron]

If we use the 10 pin breakout I fear we'll have a much smaller adoption.

The 10 pin breakout is just an 8-pin port with Ground and Power.

[boneskull]

@Frijol

@boneskull how have you used Tessel + module ports thus far?

DIY using protoboard module

[seemike]

I decided to use tessel because it is easy to access using web technologies NodeJS and JavaScript + it has all to connect to the internet. It is easy to get started and I am able to use existing node modules. This is a great plus compared to other boards!

The Rust support on the roadmap confuses me. I would not learn a new language for tessel that is hardly used anywhere else.
I think that time could be invested better in the focussing on the JavaScript stack.

[Frijol]

Thanks all for the discussion! We really appreciate your engagement with the Tessel Project's future.

We are currently discussing the next year's vision at Tesselcamp. Wait for notes to show up in the "meetings" folder of this repo, or follow along live in the #tessel-camp channel of Tessel Slack.