Not sure if I’m on a right track but I was thinking of using Meteor to control the Raspberry Pi’s. So, I’d have 2 types of the client app:
PC browser-based client app, the one to control the Pi
Pi client app. This one would exchange data using reactivity with the PC app. It can’t run in the browser because it needs to call native Pi commands. There is a good Node module for this.
And
A server app, hosted somewhere externally, that manages clients, users, etc… basically does what a server usually does.
Any ideas if it would be possible to run Pi client app as a process on Node enabled box, and not as a browser app.
Hi, I hope to get what you want to do but I would prefer to do it a bit different:
1) Run Meteor on your PI and do everything directly on the device
If you use for e.g. the current meteor universal fork, you can install meteor on your PI. More about installation and settings are available at the meteor universal blog
With that setup, you may use rpi-gpio or pi-gpio to communicate via your meteor server part and the device GPIOs.
2) Use a communication stack like MQTT
This would make a proper scaleable solution. For example on server you have running a MQTT Broker like RabbitMQ or Mosquito. The meteor instance is connected as subscriber and “reads” incoming messages.
You could “send” out your telemterics now from any device like PI (e.g. Cron job) by publishing those data via MQTT.
PS: From my point of view, your title of this post is not correctly explaning what you are looking for. Better: “Connection process to meteor server instance to exchange data” or “Subscribing non-meteor process to meteor subscription”.
Basically I want to create a robot controller, where a user uses a laptop to control the Pi CLI program, and have some server logic. I was thinking of using Meteor because of reactivity and I like the entire stack in general. The reactivity could do a good job of back and forth communication. There’s a user accounts module, and it can easily be packaged as mobile app.
I could use #3 on the Pi client, but I’d still need the regular browser app on laptop clients - though this seems to be possible by using a common external database, correct?
Using the same mongodb in your web app and your command line program(s)
The other issue I see is that some features of accounts might not supported, which may be a non starter.
You will not be able to use packages that depend directly or indirectly on any of the accounts packages
The video you posted is great. Probably more suitable for production than an early prototype.
PS: I know the title and the question would be confusing, but let’s leave it like this (as I am looking for something similar as you described in #3)
We are doing similar things like you want to do. I am very happy using the UDOO devices. They have a ARDUINO SAM3X CPU and CORTEX M9 CPU on one board. So we have installed Linux (Ubuntu Core 14.04) on the Cortex and devloped some controlling modules in Arduino INO (cpp). So this is running on one board and we have full controll over all. The power of the Cortex is pretty nice so it is no problem to run meteor on it.
Next Advantage for the UDOO against PI, it has WiFi on board and the Arduino has PWM and Analog Input signals. Also you got 3 Voltages 12V/5V/3,3V.
That’s a great setup.
If you do not need so much or only digital GPIOs then I would advise you to
You do not have to take care about dataconnection, other infrastructures … just plain meteor and nodejs.
Thanks. For now I use Express with sockets for very early prototyping (just to detect clicks, spawn/kill processes and do the GPIO). I’ll definitely try Meteor as well, but the point would be to offer many users their own portal and an app, where they could control their robots, both for config and live real-time control with camera stream (MJPEG for now).
Thanks for the heads-up on UDOO, it does seem pricey though.
Sound as an interesting project but I did not completly get how you want to design it. What do you mean with
Isnt’t that every robot will get it’s own Raspi? So if you design config and control via meteor app, everybody has his own environment. Did I make a mistake?
PS: If you are looking for a cheaper but also well suited hacker board, may have a look at pcDruino 3
I wish I could draw here. Yes, every robot has a Raspi, and when its system boots, the Meteor CLI app starts. Every robot also has an ID and that is used to identify it in the Meteor app. User logs into an (browser/mobile) app, and sees his robots, or adds a new robot based on its ID. He clicks on a robot he chooses to control and gets an interface for steering the wheels, and a camera stream from the robot.
As he’s interacting with the app, the Robot’s CLI app gets commands through reactivity. Say a user has a virtual joystick on the app, and moves it forward. Robot CLI meteor app would get a command to start driving. Same for stop, steer left, steer right, look up/down/left/right, etc…
Such app will support many users, each having many robots.
pcDuino seems similarly priced as Raspi, what are the obvious advantages?
In case that you wish to get a camera stream from each robot/pi you still need a communication directly to the robot device - otherwise the stream has its latency. I would do it like: One portal site to register Robot/Raspi and handle access data like IP etc. So inside the portal you could click on a robot and this will open a div which gets its content and camery stream directly from meteor app on robot/raspi. In case of its own reactivity on each robot/Raspi you can connect with multiple users also to any robot/Raspi. So you can still use simple direct GPIO on each Robot/Raspi/Meteor device.
The advantages from pcDUINO 3 from my point of view: 1GHZ Cortex, WiFi onboard, 1GBit Ethernet, 4GB Flash onboard, Arduino shield pins are accessible with the provided API, It consists of API to access the following interfaces:
UART, ADC, PWM, GPIO, I2C, SPI onboard
So the portal would also be a separate Meteor app, that would communicate with each individual Raspi/Meteor app? I’d need to wrap my head around how to structure it, but if the reactivity can work between the main portal and Raspi apps, then I don’t see why not.
Camera and live video is probably the most challenging part. I’m now prototyping with a simple webcam over USB, MJPEG Streamer and the results over local WiFi are pretty OK. However once I use ngrok, for outside access, the streamer has crashed a couple of times, and also having a pretty delay. So I have both the problem with the tunneling to local WIFI and finding the good transmission protocol. MJPEG is not UDP I guess, so maybe there are some WebRTC options available. This will be a whole new chapter to Google through.
The pcDUINO should has also some video hardware, I had not worked with those yet but we are running Ubuntu 14.04 Core on this device and it is pretty fast as we could se be now.
I am currently working on a distributed IoT Demo to show funtionality and the plus argument for running meteor on such devices direct. Also there would data send via MQTT to get an introduction on both technics. I think I will publish this on next weekend.
I’m also interested in this idea. The concept is to have a Meteor server running in the cloud, and have both browser and embedded systems (rasp pi, UDOO, etc) clients connected to it. Code for the embedded clients would be written in Meteor (much like browser code) so you would have one place to do your development. Meteor would automatically download new code to the embedded clients as needed (just like the browser). It seems this would be a very useful IOT architecture …