-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Which platform? #1
Comments
My vote is either Arduino or Spark. I'm not familiar with how to connect an Arduino to an API, but I do know that Spark has has wifi and pub/sub built in. Spark also uses Arduino's language, so it's compatible in that sense. Some concerns about spark: the core (and I believe the photon) operate on 3.3v. The other deal is it’s anolog inputs have 4096 bits of resolution vs arduino’s 1024, so we’d need to keep that in mind if we’re following arduino guides. edit: oh, a limitation to be aware of: the Core only operates over wifi b/g. The Photon operates over b/g/n, though. |
@ChicagoGupta do you know any hardware meetups here in Dallas that can advise us? |
@austinpray Maybe? I'd say consult with Imran or Kris from Code Collective. I can twitter them in to the convo. |
Tessel 2 Does have a virtual machine we can work with too so we can start without any hardware - @nathanielks and I were looking for something like this. See: https://github.com/tessel/t2-vm and: https://github.com/tessel/t2-cli Also I just got an email from the Tessel team
And they have moved to an open governance model similar to io.js
Plus then it keeps us teaching html/css/js like the group said they wanted learn at the first meeting. |
Also, I definitely vote on using cylon.js since it supports arduino, spark, tessel and others. It's a great framework and then all we do is change out 'adapters' similar to how ember data or rails activerecord works with changing dbs |
So, one of my concerns with using Tessel, despite having emulators, is timeline. Can we really work quickly and accurately if we're just using an emulator? Part of my calculated concern is when we think we'll get started on everything. Do we see this project taking a month? A few months? A year? Is waiting two months (or longer, let's be real here) worth it for hardware we're unfamiliar with, and hardware that's (comparatively) expensive at that? As long as we're cool with timeline, I'm good. Re cylon.js: I do like the idea that we can plug a bunch of different microcontrollers into it. And I like that most people could jump on the project. I'm hesitant in one sense as it's a layer of abstraction I don't think we don't need. Part of this project is to learn new things, and being already familiar with JS, it doesn't excite me to use JS for hardware. Let's get close to the metal! Squeeze out all that performance! And just to be clear: I'm only critiquing ideas, not people. I think you're awesome, @jhliberty 😄. Let's make this the best damn internet-plant-waterer we can. |
@jhliberty though another point on the side of cylon... it'll make switching to another microcontroller pretty simple should we decide to change down the road... |
Just my 2 cents as someone who's not gonna get to play with the hardware side of things too much: I agree with @nathanielks about working on a closer level to the hardware. I don't know anything about cylon.js but if there's a bunch of abstractions, it might defeat the purpose of the project. Since this is more of a learning opportunity, it is more interesting to dig into the hardware assembly languages or whatever than to just write javascript for our machines. We're not making money on this and we don't have a firm deadline to get this up and running. But I do understand that more people can get involved quickly if we can just throw together some js and make the robot work. Another potential advantage of using the device specific technologies is that we can access all the features of the device without having to worry about cylon support. Feel free to correct me if I'm wrong, because I'm definitely not an expert here. |
My two cents is to go with an MSP430 (the Texas Instruments flavor of MCU), because they have pretty cheap (~$20) Wifi modules (CC3100) that are fairly well documented, and the community is very active as far as questions go. Another plus is that they are compatible with all Arduino modules and use comparable code, so that gives us access to both Texas Instruments and Arduino support and modules which is great. We can also get all these parts in the next week or less, so that's cool. |
We need to decide which platform we are going to use to run the bot.
@jhliberty has a couple tessel 2's on order. However they do not ship til August. We need to get started before then, so we can't wait this long. One option here would be to buy a tessel 1 and then upgrade to tessel 2 when we get them.
Another option is definitely Arduino. I know for a fact Arduino has ready-made modules for water pumps and climate sensors.
We should base our decision on:
The text was updated successfully, but these errors were encountered: