We are setting up a driver simulator that could be working together with a 
remote controlled minicar with webcam.
The direction, acc and video from the minicar will be feeded back to the 
driversimulator with a 6 DOF motion base ( trough a bit of filtering program ) 
. Seems a bit strange application but we let our students work on this as a 
first stage towards our main goal.
The protocol would be able to transfer state packages at 10 packaged per 
second. According to naval postgrade school in Monterey CA this could be 
possible. Appreciate your opinion.
Btw project described at 
wbsp.arb.ltu.se/Motionbase<http://wbsp.arb.ltu.se/Motionbase>
/Sven-Erik Tiberg
Luleå Univ of technology
Sweden




Skickat från min iPhone

17 dec 2012 kl. 17:46 skrev "Anthony Rowe" 
<a...@ece.cmu.edu<mailto:a...@ece.cmu.edu>>:

Hi all,

Great to see so much interested in XMPP for IoT applications.  The XEP was 
basically a summarization of how we had been using XMPP and pubsub in our 
sensor andrew project.  We were also lucky enough to get a fair amount of input 
form Charles at Google with some interesting use-cases and a few idea on 
reducing message traffic.  The main hangup was that the XMPP council didn't 
like the idea of linking sensors and actuators and there was some concern if 
pubsub was generally a good fit for actuation.  We basically decided that as 
researchers in a University environment we would just keep doing what we were 
doing and revisit the XEP in the future if there was more interest.    One easy 
fix would have been for us to split the XEP into a sensor and actuator document.

I would be very interested to hear about how you all have been structuring your 
XMPP communication.  Is it similar to what we proposed?  Is anyone using 
pubsub?  We are still actively using our proposed model with a few minor 
changes to the XEP.  Our most recent version of the XEP document can be found 
here:
http://sensor.andrew.cmu.edu/xep/sox-xep.html

We also have a simple tutorial for getting up and running with our tools:
http://sensor.andrew.cmu.edu:9000/raw-attachment/wiki/quick-start/sensor-andrew-tutorial.pdf

As for implementations, we have a C, java and python version of our library 
(called SOX) that we have continued to develop.   We have been focusing our 
recent efforts on the slightly higher-level problems associated with data 
storage, meta information management and application hosting.  These all for 
the most part exist above the XEP which is just our simple message passing 
format.

I wouldn't be opposed to revamping our XEP with other's inputs and trying to 
resubmit.  We have been getting interest from our corporate sponsors to take 
another shot at the XEP.

    -Anthony

On Dec 17, 2012, at 11:16 AM, mat henshall 
<m...@squareconnect.com<mailto:m...@squareconnect.com>> wrote:

We are using XMPP for both sensor reporting and control for building and home 
automation applications. We have implemented a very rich set of stanza's that 
cover almost all common types of devices and it is designed to work on very low 
resource embedded devices. This implementation is currently in closed beta 
although there are some very large brands who have started to develop 
applications and hardware using our protocol and technology. Our intention is 
to make the protocol public once we had a full working public available 
implementation.

When we became aware of the proposed XEP extension mentioned here we were 
already a long way down the road with our own, and as there is so much more to 
making a complete system than is exposed in this XEP, we felt we needed a 
working implementation to compare and contrast and make meaningful 
contributions based on experience...

We would be excited to work with others on creating a standard... the problem 
as always is time to commit to this exercise. That being said, we do have 
executing code and multiple devices talking to each otehr across continents... 
so I think we are at the stage where we could add to any serious attempt for 
standardization.

Mat







On Mon, Dec 17, 2012 at 9:54 AM, Hannes Tschofenig 
<hannes.tschofe...@gmx.net<mailto:hannes.tschofe...@gmx.net>> wrote:
Hi all,

I was actually wondering myself about the status of XMPP & SIP usage for 
sensors. I dropped Peter a mail a month ago to hear more about the deployment 
situation.
It seems that if there are implementations then they are using HTTP.

Ciao
Hannes

On Dec 17, 2012, at 5:47 PM, Matthew Wild wrote:

> On 17 December 2012 12:35, Peter Waher 
> <peter.wa...@clayster.com<mailto:peter.wa...@clayster.com>> wrote:
>>
>> Hello,
>>
>> I’m writing to you to, to ask about the status of the following document:
>>
>> http://xmpp.org/extensions/inbox/sensors.html
>>
>
>> I’m interested in developing extensions for allowing sensor data 
>> communication and IoT, among other things. We have multiple applications 
>> using XMPP and sensors. Before proposing an extension by ourselves, I’ve 
>> been waiting to find colleagues working in the same area, so we could 
>> propose an extension together, this increasing the probability for it to 
>> become useful.
>>
>> What is the status of the above mentioned document? Is it set in stone, or 
>> is it possible to work on it, redefine parts of it, etc., in order for it to 
>> become more general and suitable also to our needs? Are you able to invite 
>> other authors to partake in the development of this proposed extension?
>
> It was rejected by the council at its meeting 2011-04-27:
> http://mail.jabber.org/pipermail/council/2011-May/003164.html
>
> Nathan posted his reasoning here:
> http://mail.jabber.org/pipermail/standards/2011-May/024545.html - and
> the discussion continued here:
> http://mail.jabber.org/pipermail/standards/2011-May/024547.html
>
> No new version was submitted as far as I know, and I know of no public
> implementations of the protocol (that's not to say there aren't any of
> course...).
>
> Regards,
> Matthew




--

Mat Henshall
Founder and CEO, Square Connect, Inc.
San Jose, CA
www.squareconnect.com<http://www.squareconnect.com/>
cell: 650.814.7585

Reply via email to