prototyping Archive

As make magazine reports, our friends from Tellart just released a fabulous tutorial for a toolkit and code samples to build prototypes that bind any android device with Arduinos. You’ll definitely find some great examples to get started within the 25 samples included, so we encourage you to give it a try!

This week we’re happy to update that list of toolkits with a suite of materials focused on connecting any Android device (mobile or tablet) with the Arduino ADK microcontroller, with the Processing language to tie them together. The materials – a combination of “how-to” installation guides, working Arduino and Processing sample code, and educational exercises – walk through the set-up process and provide some basic starters for making a functional application or game. The 25 samples include modules such as the code you need to create a “color picker” on the Android and have it drive the color of an LED attached to the Arduino, or to send an RFID number from a scanner to the phone, or to create a basic oscilloscope by graphing the output of a potentiometer on the Android screen. It’s tailored to get beginners going, or to give more experienced coders a quick leg up in using the three (Android, Processing, and Arduino) together.

[Source link]

Folks, this is a guest post from Kerwin Lumpkins who is working on a cool project he put on Kickstarter (there’s a video there too), check it out!! He has built a prototype and would like to have it funded to produce more of these. As we’re always happy to share cool projects made by others as well, here you go :)

The Ard-Vark is a basic electronics box that has wifi built in to allow easy remote control through a mobile app, and has the following features:

  • Arduino compatible (can use the Arduino IDE as is, based on Leonardo platform)

  • USB connection to PC for serial or re-programming

  • Mobile app available for download (iPhone/iPad/iPod/Android)

  • Built in wifi for wireless remote control (Roving Networks RN-171)

  • 4 servo motor headers

  • 2 small DC motor headers

  • Built in light sensor

  • Built in temperature sensor

  • 3 analog sensor inputs with ground and 5V power supplied

  • 3 digital I/O headers with ground and 5V power supplied

  • LED

  • Speaker

  • Can be powered by 9V battery or 9V AC adapter plug

  • Mounted in a durable plastic case, cutouts for headers, silkscreen labeling of ports

b63206cba279f3e458cdc37a0fe53f78.png

Tech details of the Ard-Vark Prototype

Figure 1 shows a block diagram of the Ard-Vark prototype. Blocks in green are parts that are exposed on the outside of the case. Blue are parts that are covered up inside the case. For clarity, I didn’t have a block for the level shifting from wifi module to the microcontroller, but those parts can be seen on the front of the circuit board. The numbers show how many lines were needed to implement that function.

b127d97d74c24b946f71e5c36e6acecc.png

Figure 1: Block diagram of the Ard-Vark

For the prototype, I designed a board in EAGLE that would allow me to solder on Sparkfun’s Pro Micro (5V) and RN-XV module that uses the RN-171 module from Roving Networks. If the project is funded, the parts on the Pro Micro board and the RN-171 module will be surface mount soldered onto a single circuit board. This will lower the price.

All pins accessible?: “Will there be headers for all pins on the micro?” – Yes. The Ard-Vark will not load the headers, but I will place the holes on the circuit board. I intend to put the standard Arduino header pattern on the board for those that want to use that as well.

About the Arduino IDE: The pro micro (and hence also the Ard-Vark) is based on the ATMega 32U4 microcontroller, which is supported for the Arduino under the Leonardo model. Arduino has not fully released this yet, but I had no problem using the standard Arduino IDE after making some simple changes in the boards.txt file and downloading Sparkfun’s driver. Look at the Pro Micro page for a tutorial if you’re interested. For the final version, I will write up a manual that has installation instructions, schematics, source code, suggestions for hacking, etc.

The prototype Ard-Vark has a Pro-Micro board with headers that solder onto the main board. The RN-XV module similarly solders onto the main board. Then the main board has header connectors, the AC power plug, 5V regulator (beefy one that can power all 4 servos at once), etc. In photo below, the surface mount 5V regulator is mounted on the bottom side of proto board. You can see rework (yellow tape) where I used a through hole electrolytic cap. I didn’t allow enough room for a SM cap on the top side. So I put the reg and cap on bottom. Final version will fix this little error.


8a7f29fb1cb4ca975792a75608165022_d32x.png

Fig2. Ard-Vark with the back cover removed

90e9adb2d8d8275daba730c2c688d29f.png

Fig. 3 Proto Board top side with servo headers, etc. Speaker is at bottom right.

More rework is evident on the top side of board. I realized that the the power indicator LED was too close to the light sensor (could influence the reading if in a dark room), so I moved the LED to right of the power switch. The yellow tape insulates leads of a through hole resistor. I also had to solder some wires onto the blue LED (just to left of the speaker) since the LED is too far below the hole. Final version will use a through hole LED to solve this. Light sensor (TMP-36 from analog devices) is the TO-92 through hole package part at top right. In the center of the board are surface mount parts that do level shifting for the RN-171 module. It runs at 3.3V while the microcontroller runs at 5V. One more problem I got sick of dealing with.

Finally, not shown is a motor control circuit. I decided after I built this proto board that offering DC motor control built in would be a good feature. Final version will make use of a motor control IC like the L293D. So the motors can only draw at max about 1 Amp. This will be fine for small motors like those used on small mobile robots.

c8417a5e4753666607d7365626a21fa1_8ps5.png

Fig.4 Proto board back side showing the Pro Micro and RN-XV modules from Sparkfun and power plug.

On the bottom side of the board are the two modules from Sparkfun, power plug and (temporarily), the 5V regulator.

fe1d26a535bc7368a8c615e16736b903.png

A view showing the “front” of the Ard-Vark. Note that this board has the USB micro connector missing. The micro B surface mount connector on the Sparkfun Pro Micro broke off after 10 or so plug/unplugs. I put it back on with super glue, but it came off again (hence the nasty looking mess in the middle). One change I’ll make in final board is to use a mini B through hole connector for improved strength.

The Story of the Ard-Vark (for those that are interested)

I made the Ard-Vark because I frequently like to add motion to projects using servo motors; from animatronics projects at holidays to building something that’s actually useful, to making something to scare co-workers when they sit down in their cubes. I grew tired of re-inventing and building this kind of thing again and again. So I finally designed a circuit board that would allow me to integrate wifi and Arduino controller and servo headers and motor controller and 2 wire motor headers and speaker, etc, all into one design. I also got tired of having projects stop working because exposed copper caused shorts, handwired solder joints came loose from strain, etc so I designed a case. And I got tired of having to power it with a USB cable to a PC, so I designed in a 9V battery and an AC adapter plug. And then I wrote a mobile app to allow me to control it remotely. All of that, I called the Ard-Vark.

Some friends were interested in getting one, so I thought I would list it as a project on kickstarter.com to see if there was enough interest to produce them in quantity to make the price reasonable. If I made one or two of these at a time, it would cost about $120 in parts and 2-3 hours to build and test one. I don’t have time to sit and build these. It just wouldn’t be worth my time. But if I can make several hundred of them at once, it brings the price down to a reasonable $100.

Who would use the Vark?

There are three types of people using things like the Ard-Vark out there today:

  1. Creative and technically talented folk that DO want to deal with electronics and motor control and highly technical stuff. DIY’selfers, beginning electronics class students, etc.

  2. Creative people that hate technical stuff but that want to build projects using electronics.

  3. People that for one reason or another, do not want to fool with building the electronics base and just want to get going on a project.

Group 3 sounds like it’s just group 2 stated in a different way. But I’m in group 3. I’m an electrical and software engineer with over 15 years experience building projects both professionally and for hobby. I’m highly technical.

Group 1 are the do it yourself types. They do this kind of work because they want to learn this stuff and building and soldering and tinkering IS the whole point of what they do. But at some point, Group 1 folk turn into Group 3 folk. Like me. I changed into Group 3 guy after about 7 years. Sometimes, I just want to pick up a box, plug in some servos, turn it on and go. And that’s why I made the Ard-Vark.

Group 2 are becoming more prevalent today. Artists that want to add motion and interactivity to their creations. But they want to concentrate on their creative project, not on learning technical stuff.

This article is written for Group 1 folk that are interested in what is under the hood of the Ard-Vark, viewing it as just another project. The source code will be open and free to use, so the vark can be modifed to work in your project as you want it. The vark is very flexible in that it can provide “it just works” functionality out of the box, but can also be reconfigured.

As Google recently announced their plans to move in the home automation world with Android at home (and we are still wondering why they waited so long to do it), I thought I would share my view on that. I do believe there are many opportunities ahead for the “home operating system” domain. The combination of cheap, yet powerful networked digital appliances in the house (NAS, networked media players, WiFi routers, etc) along with an extensible application framework, and a market place for buying new applications (or installing drivers, etc) – will be a killer combo for home automation to take off, especially for building management systems (I’m not yet convinced the market is ready for consumer home automation – unless you’re millionaire and want to show off by turning off lights by clapping hands). But I do believe the Web of Things in this vision can be a solid innovation enabler by making it easy to integrate all kinds of devices and develop new home automation mashlets (mashup & applets – does this even exist? or should we call these phy-ma-les = PHYsical MAshup appLEtS? no? ok…. fine…).

But for this to happen, “we need a hub to receive all the sensors” according to a recent blog post. I disagree. We don’t need one hub, we need many hubs. But even more so, we need the ability to establish direct connectivity between anything electronic and applications. Exactly in the same way as one can search and download specific stuff from particular users that have it in a p2p network.

We have been exploring the field of home automation since the early days of WoT, and we have prototyped several versions of a fully web-based “smart home gateways” that allows the integration of heterogeneous embedded devices into high-level interactive, mobile, and event-driven Web applications. Our first iteration was built with Samuel Wieland [4,5] project, and then superseded by Aparat [3,6], done by another former student Vlatko Davidovski with whom we designed a modular framework (based on OSGi) to easily create applications, develop new devices drivers, that supported Web-based messaging (both pubsubhubbub and Comet), microformat-based resource and device discovery over HTTP, among other features. With another student (Andreas Kamilaris) we have designed in 2009 HomeWeb, a Web-based framework for integrating sensor networks on the Web and afterwards extended it to the home automation domain [1]. We also recently published a journal paper on this work as well [2].

Aparat_idea.jpg

As we’re nearing to IPv6 (dooms)day (actually passed it), more and more routers and networks will be switching (or at least supporting) it, and this will pave the way to better adoption and ripening of the market for Wi-Fi and other IP-enabled consumer electronics. On top of this ecosystem of interconnected devices, a Web-based framework that facilitates development and distribution of applications will clearly unlock the potentials and an open market that drive us away from the currently dictatorial and closed solutions in this domain. At least this is what we hope for.

Clearly, the biggest challenge ahead (and one that I keep seeing only marginally addressed in our research field so far) is security, authentication, and devices sharing. If your whole house is connected to the Web, there are major risks involved as virtually one could entirely control your house (turn off security systems), spy by monitoring all your movements (or hot summer nights via surveillance cameras), or do even more critical things such as lock elevators, close doors, and so on.

The security issue leads us to the following question as to what would be best? An open source security solution that everyone knows and can improve upon by eliminate bugs (thousands pair of eyes are better than a few), with the risk that any hacker can find out exactly how the whole system works? Or a black-box proprietary closed-source system that is hard to analyze and crack, which might be in fact more bugged? Also, how one can combine various modalities for securing that you are really “you” and you are at your home (RFID can hacked, mobile phones can be lost, pin codes can be transmitted). Also, what will be the role of biometric ID solutions (retina scanners, etc)? As long as authentication data is sent by an application over the network, then it can be forged with another “software emulation”, how this could be prevented?

We would love to have your opinion on these questions and feel free to join our discussion in the comments (or on our LinkedIn or facebook pages). We’d really appreciate if you would share with us projects and services that you think can solve this issue.

  1. Andreas Kamilaris, Vlad Trifa and Adreas Pitsillides. The Smart Home Meets the Web of Things. Int. J. of Ad Hoc and Ubiquitous Computing, 7(3), 2011. [pdf]
  2. Andreas Kamilaris, Vlad Trifa and Andreas Pitsillides. HomeWeb: An Application Framework for Web-based Smart Homes. In Proceedings of the 18th International Conference on Telecommunications, Ayia Napa, Cyprus, May 2011. [pdf]
  3. Vlatko Davidovski (M.Sc. thesis at ETH Zurich). A Web-oriented Infrastructure for Interacting with Digitally Augmented Environments.
  4. Samuel Wieland (M.Sc. thesis at ETH Zurich). Design and Implementation of a Gateway for Web-based Interaction and Management of Embedded Devices.
  5. Vlad Trifa, Samuel Wieland, Dominique Guinard and Thomas Michael Bohnert. Design and Implementation of a Gateway for Web-based Interaction and Management of Embedded Devices. In Proceedings of the 2nd International Workshop on Sensor Network Engineering (IWSNE’09), Marina del Rey, CA, USA, June 2009. [pdf]
  6. Vlad Trifa, Dominique Guinard, Vlatko Davidovski, Andreas Kamilaris and Ivan Delchev. Web Messaging for Open and Scalable Distributed Sensing Applications. In Proc. of the 10th International Conference on Web Engineering (ICWE 2010), Vienna, Austria, June 2010. [pdf]

Besides the fact that we are big Sun SPOTs fans, we also got increasingly more interested in the OpenPicus platform, not only because the constant motivation of the project founder Claudio Carnevali is impressive but mostly because the FlyPort (the OpenPicus wireless sensor node) is featuring a WiFi module and a Webserver (according to them our WoT community influenced them on that point) which makes it a nice, compliant, Web of Things device. ;-)

Yesterday, the OpenPicus project released their free, open-source, IDE which supposedly makes it really easy to develop Web of Things applications backed by Wireless Sensor Nodes.

The team asked us to post some news about the IDE, instead of that, I decided to test it and report here:

  1. Got the IDE here. First small decrease of my tremendous motivation: the IDE is .NET/Windows-based, hem, slightly strange choice provided the WoT community is probably 50% mac, 50% Linux (or it least I’d like to believe so), but let’s not be so futile, and simply remove the dust off my XP VMWare virtual machine.
  2. The IDE requires the .NET 4 framework which installed smoothly on my VM.
  3. Unzip, sorry un-rar (Duh! Ok, let’s download 7 Zip) the IDE.
  4. No install required, neat, the IDE starts smoothly. It has a familiar Office 2007 / 2010 look and feel. It’s actually not bad, simple and quite efficient. The code-completion works fine which really helps discovering the OpenPicus and FlyPort API.
  5. I plug my FlyPort for the first time in my VM, again it is smoothly discovered as a USB/Serial port, which means the install does not need any additional driver.
  6. This video, guides you through your first FlyPort project. The whole process ran smoothly on my VM as well (for people using Linux like me and wanting to use the OpenPicus IDE in a VM, make sure you get a WiFi dongle, as VMWare maps any native WiFi interface of your computer to a wired network in the guest operating system.
  7. The video also shows how to deploy the native Webserver to the FlyPort, which takes, in essence, 3 clicks and is entirely customizable so that you can make your services truly RESTful, very neat!

To sum up, I need more experience with the device to really judge it (coming soon!) but it seems like a very good platform for easly prototyping Web of Things applications, very good job! On the drawbacks I would have liked a Java, cross-platform, version of the IDE and Flyport stack rather than a .Net one but I must admit that the IDE’s simplicity and integration is impressive and after all what only really matters to us is the out-of-the-box ability to hide the FlyPort’s internal language behind a Web API (more to come on that part as well, I’ll test the FlyPort against the Web of Things cookbook!).