[B.A.T.M.A.N.] B.A.T.M.A.N Suitability for MAGIC 2010

[B.A.T.M.A.N.] B.A.T.M.A.N Suitability for MAGIC 2010

[Michael Fazio]

Hello,

		My name is Michael. I am currently working on a large robotics  
project and I am thinking of using B.A.T.M.A.N to facilitate a MANET  
to communicate between a number of bots and a base station. I was  
hoping to get a bit of information regarding the suitability of  
B.A.T.M.A.N for such an application. Any information would be helpful  
(general or specific). Here are some of the details of our project.

We will be using up-to 14 bots in our project (each must be network  
aware).
The area that our bots will be operating in is approximately the size  
of a football field.
There are both indoor and outdoor areas that must be navigated with a  
significant amount of obstacles.
We will be using 802.11a,b,g and possibly n as well as one or more  
long range VHF links which I am hoping to setup as additional entry  
points to our bot network.
We have various types of data to be communicated on our network  
including, GPS, basic telemetry, control message, imagery, UAV feeds,  
point cloud info etc.
Some data such as GPS and telemetry is realtime and need not be  
reliable (we are considering simply UDP broadcasting this data). Other  
data such as imagery and control messages will require stable links  
and need to be relatively reliable.
We are not yet sure if we will be deploying any specific middleware  
technology although I am partial to pub/sub middleware. Are there any  
such middleware that can complement B.A.T.M.A.N?

I was hoping to know what type of issues I might run into using  
B.A.T.M.A.N adv in such a scenario. For instance, what kind of  
throughput might I expect in the described environment? Link stability  
issues? General suitability? How would B.A.T.M.A.N compare to OLSR or  
Babel? I am really interested in anything that anyone has to offer.

The reason I am pushing for B.A.T.M.A.N is because of the ability for  
us to develop our application layer using IPv4 TCP/UDP on-top of a  
mesh network driven by routers running openWRT & B.A.T.M.A.N. I want  
to take as much network layer knowledge away from out application layer.

Also, does anyone know of other similar usages of B.A.T.M.A.N?

I have a bunch of studies from various organizations comparing  
B.A.T.M.A.N to other solutions but I would really appreciate to hear  
what the mail list users have to say about their own experiences with  
B.A.T.M.A.N.

I hope this is the right place to be asking all these questions!

Thanks Batmen & Batwomen!

Michael

Re: [B.A.T.M.A.N.] B.A.T.M.A.N Suitability for MAGIC 2010

[Linus Lüssing]

[-- Attachment #1: Type: text/plain, Size: 4605 bytes --]

Hi Michael,

> My name is Michael. I am currently working on a large robotics
> project and I am thinking of using B.A.T.M.A.N to facilitate a MANET
> to communicate between a number of bots and a base station. I was
> hoping to get a bit of information regarding the suitability of
> B.A.T.M.A.N for such an application. Any information would be helpful
> (general or specific). Here are some of the details of our project.

Your project sounds very exciting! I had a little look at the MAGIC 2010
website and what it says about the tasks that have to be done and what kind of
time span and how much mobility we're talking about here and what the specific
tasks are on the MAGIC 2010 website. However, I/we have little experience with
such challenges and setups. Most people use batman to create wireless networks
within buildings / houses / cities. Could you tell us a bit more about why you
want to run mesh on the robots itself and not using the common infrastucture
mode on the base station for example (as I assume this has been used in robotic
challenges before)? Have other people tried mesh on bots before and what were/are
the problems you expect?

So far, I haven't heard of anyone using B.A.T.M.A.N. in a robotics scenario
before, though I've always been interested in seeing B.A.T.M.A.N. in a 
swarm-robotics scenario one day :).

> We have various types of data to be communicated on our network
> including, GPS, basic telemetry, control message, imagery, UAV feeds,
> point cloud info etc.
> Some data such as GPS and telemetry is realtime and need not be
> reliable (we are considering simply UDP broadcasting this data). Other
> data such as imagery and control messages will require stable links
> and need to be relatively reliable.
> We are not yet sure if we will be deploying any specific middleware
> technology although I am partial to pub/sub middleware. Are there any
> such middleware that can complement B.A.T.M.A.N?

14 mobile bots should be perfectly fine for batman to handle. Like most routing
protocols, batman does not interact with other software components directly.
It will try to be as invisible as possible and allows all standard network
operations to behave as expected. Nothing special or fancy required here.

On the other hand it is important to realize that batman comes in 2 flavors:
* The batman daemon operating on layer 3 (like most other routing protocols
do).
* The batman-adv kernel module building a layer 2 network across the wifi
nodes.

The later comes with some handy features you might want to look at. Unlike the
layer 3 routing protocols it does not only decide about the routing of the
traffic but handles the traffic forwarding itself. Therefore, it can be optimized
for your traffic needs. For example, broadcasting UDP messages over wifi is not
as easy as it sounds (broadcasted packets are getting lost more often than unicast
packets here). batman-adv already has a feature built-in to send broadcasts up to
3 times along each hop to increase the probability of getting the data transmitted.

> I was hoping to know what type of issues I might run into using
> B.A.T.M.A.N adv in such a scenario. For instance, what kind of
> throughput might I expect in the described environment? Link stability
> issues? General suitability? How would B.A.T.M.A.N compare to OLSR or
> Babel? I am really interested in anything that anyone has to offer.

Usually in mesh networks the rule so far was, that you can expect about half
of the bandwidth with each additional hop starting with ~25MBit/s payload
throughput in 802.11a/g networks for direct neighbours. In 802.11n you can
expect a maximum capacity of ~100MBit/s in ideal conditions with a wifi card
capable of 3x3:3or 4x4:4 settings as far as I know.
For QoS there seems to be the 802.11e standard especially for wifi networks,
but I have no experiences with that one.
I can't say that much for the protocol comparision as I haven't been
using/testing current implementations of OLSR or BABEL lately and I'm also
only aware of two comparison papers. I think it comes down to try what works
best for you and what your requirements are.

When you start your tests you might want to reduce the originator interval to
50ms (the minimum value) to make sure the routing entries are updated quite
often. Batman's default settings are optimized for less traffic but slower
updates. Buildings tend to move much less. ;-)

Hope I could answer most of your questions so far. More questions
always welcome :).

Cheers, Linus

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [B.A.T.M.A.N.] B.A.T.M.A.N Suitability for MAGIC 2010

[L. Aaron Kaplan]

On Mar 11, 2010, at 3:12 PM, Michael Fazio wrote:

> Hello,
> 
> 		My name is Michael. I am currently working on a large robotics project and I am thinking of using B.A.T.M.A.N to facilitate a MANET to communicate between a number of bots and a base station. I was hoping to get a bit of information regarding the suitability of B.A.T.M.A.N for such an application. Any information would be helpful (general or specific). Here are some of the details of our project.
> 
> We will be using up-to 14 bots in our project (each must be network aware).

It will scale to 14 nodes :)

(...)

> 
> 
> I was hoping to know what type of issues I might run into using B.A.T.M.A.N adv in such a scenario. For instance, what kind of throughput might I expect in the described environment? Link stability issues? General suitability? How would B.A.T.M.A.N compare to OLSR or Babel? I am really interested in anything that anyone has to offer.
> 
I think all protocols will be fine for 14 nodes. But please report your findings.
I assume that B.A.T.M.A.N. will be a bit slow (depends on the timeing settings of course) when you have many routing switches/high mobility (in the presence of long paths) but that it will find good paths instead (there is always a trade-off between these things).

It should be easy enough to try out all three protocols! I am especially interested in a highly mobile setup.


> The reason I am pushing for B.A.T.M.A.N is because of the ability for us to develop our application layer using IPv4 TCP/UDP on-top of a mesh network driven by routers running openWRT & B.A.T.M.A.N. I want to take as much network layer knowledge away from out application layer.

IMHO you will have this with all three protocols.

Best,
a.

Re: [B.A.T.M.A.N.] B.A.T.M.A.N Suitability for MAGIC 2010

[Michael Fazio]

Hi Linus (and others who responded),

									Well I don't remember mentioning MAGIC 2010, but you are  
correct, the project is MAGIC 2010. Good investigatory work! :) Right  
now, the use of B.A.T.M.A.N, OLSR, and Babel are possibilities but no  
decision has been made regarding their eventual use.

The reason I was looking into these technologies is because of the  
"seamlessness" of their operation and the fact they enable multi-hop  
routing for IPv4 in ad-hoc network setups. The hidden node problem  
could be a show stopper as some of the data we are transferring such  
as streaming video and manual control of UGVs require relatively  
stable and continuous channels of communication. Furthermore, message  
passing may not necessarily be done with the use of a middleware.  
Realtime unreliable data such as GPS and telemetry information may  
simply be pushed onto the network in UDP packets. I would prefer to  
use a nice middleware that performs well in MANET environments and I  
am still evaluating the possibility of this. If you have any  
recommendations that would be good!

Further on the topic of using BSS. We do expect wifi dead-spots and we  
must absolutely try to minimize these. So the multi-hop nature of  
something like B.A.T.M.A.N (i was hoping) would help in that regard.

I can't guarantee that we will use B.A.T.M.A.N but I will try to  
evaluate it in the field eventually.

Thanks!

Michael

On 15/03/2010, at 4:41 AM, Linus Lüssing wrote:

> Hi Michael,
>
>> My name is Michael. I am currently working on a large robotics
>> project and I am thinking of using B.A.T.M.A.N to facilitate a MANET
>> to communicate between a number of bots and a base station. I was
>> hoping to get a bit of information regarding the suitability of
>> B.A.T.M.A.N for such an application. Any information would be helpful
>> (general or specific). Here are some of the details of our project.
>
> Your project sounds very exciting! I had a little look at the MAGIC  
> 2010
> website and what it says about the tasks that have to be done and  
> what kind of
> time span and how much mobility we're talking about here and what  
> the specific
> tasks are on the MAGIC 2010 website. However, I/we have little  
> experience with
> such challenges and setups. Most people use batman to create  
> wireless networks
> within buildings / houses / cities. Could you tell us a bit more  
> about why you
> want to run mesh on the robots itself and not using the common  
> infrastucture
> mode on the base station for example (as I assume this has been used  
> in robotic
> challenges before)? Have other people tried mesh on bots before and  
> what were/are
> the problems you expect?
>
> So far, I haven't heard of anyone using B.A.T.M.A.N. in a robotics  
> scenario
> before, though I've always been interested in seeing B.A.T.M.A.N. in a
> swarm-robotics scenario one day :).
>
>> We have various types of data to be communicated on our network
>> including, GPS, basic telemetry, control message, imagery, UAV feeds,
>> point cloud info etc.
>> Some data such as GPS and telemetry is realtime and need not be
>> reliable (we are considering simply UDP broadcasting this data).  
>> Other
>> data such as imagery and control messages will require stable links
>> and need to be relatively reliable.
>> We are not yet sure if we will be deploying any specific middleware
>> technology although I am partial to pub/sub middleware. Are there any
>> such middleware that can complement B.A.T.M.A.N?
>
> 14 mobile bots should be perfectly fine for batman to handle. Like  
> most routing
> protocols, batman does not interact with other software components  
> directly.
> It will try to be as invisible as possible and allows all standard  
> network
> operations to behave as expected. Nothing special or fancy required  
> here.
>
> On the other hand it is important to realize that batman comes in 2  
> flavors:
> * The batman daemon operating on layer 3 (like most other routing  
> protocols
> do).
> * The batman-adv kernel module building a layer 2 network across the  
> wifi
> nodes.
>
> The later comes with some handy features you might want to look at.  
> Unlike the
> layer 3 routing protocols it does not only decide about the routing  
> of the
> traffic but handles the traffic forwarding itself. Therefore, it can  
> be optimized
> for your traffic needs. For example, broadcasting UDP messages over  
> wifi is not
> as easy as it sounds (broadcasted packets are getting lost more  
> often than unicast
> packets here). batman-adv already has a feature built-in to send  
> broadcasts up to
> 3 times along each hop to increase the probability of getting the  
> data transmitted.
>
>> I was hoping to know what type of issues I might run into using
>> B.A.T.M.A.N adv in such a scenario. For instance, what kind of
>> throughput might I expect in the described environment? Link  
>> stability
>> issues? General suitability? How would B.A.T.M.A.N compare to OLSR or
>> Babel? I am really interested in anything that anyone has to offer.
>
> Usually in mesh networks the rule so far was, that you can expect  
> about half
> of the bandwidth with each additional hop starting with ~25MBit/s  
> payload
> throughput in 802.11a/g networks for direct neighbours. In 802.11n  
> you can
> expect a maximum capacity of ~100MBit/s in ideal conditions with a  
> wifi card
> capable of 3x3:3or 4x4:4 settings as far as I know.
> For QoS there seems to be the 802.11e standard especially for wifi  
> networks,
> but I have no experiences with that one.
> I can't say that much for the protocol comparision as I haven't been
> using/testing current implementations of OLSR or BABEL lately and  
> I'm also
> only aware of two comparison papers. I think it comes down to try  
> what works
> best for you and what your requirements are.
>
> When you start your tests you might want to reduce the originator  
> interval to
> 50ms (the minimum value) to make sure the routing entries are  
> updated quite
> often. Batman's default settings are optimized for less traffic but  
> slower
> updates. Buildings tend to move much less. ;-)
>
> Hope I could answer most of your questions so far. More questions
> always welcome :).
>
> Cheers, Linus

Re: [B.A.T.M.A.N.] B.A.T.M.A.N Suitability for MAGIC 2010

[Marek Lindner]

Hi,

> Well I don't remember mentioning MAGIC 2010, but you are   correct, the
>  project is MAGIC 2010. Good investigatory work! :) 

the email's subject contained the necessary hints.  ;-)


> Furthermore, message passing may not necessarily be done with the use of a
> middleware. Realtime unreliable data such as GPS and telemetry information
> may simply be pushed onto the network in UDP packets. I would prefer to  
> use a nice middleware that performs well in MANET environments and I  
> am still evaluating the possibility of this. If you have any  
> recommendations that would be good!

What exactly are you looking for ("middleware" is a pretty broad term) ? An 
application that can send GPS data through the network ?


> Further on the topic of using BSS. We do expect wifi dead-spots and we  
> must absolutely try to minimize these. So the multi-hop nature of  
> something like B.A.T.M.A.N (i was hoping) would help in that regard.

Yes, batman can help you "extending" the network. But the biggest troublemaker 
will be the wifi driver because adhoc mode isn't that well supported. 99% of 
the users want infrastructure mode, therefore developers work on that first. 
Adhoc mode comes later (if at all), is often buggy and not well tested. The 
wifi communities get around this issue by focussing on hardware which either 
comes with an open driver (e.g. atheros chips) or have a working adhoc mode 
implementation. Depending on how much freedom of hardware choice you have I'd 
suggest you carefully pick your wifi chips.


> I can't guarantee that we will use B.A.T.M.A.N but I will try to  
> evaluate it in the field eventually.

Please, share the results of these tests with us. Even if you don't choose 
batman we would be very interested to find out what we can improve.  :-)

Cheers,
Marek

Re: [B.A.T.M.A.N.] B.A.T.M.A.N Suitability for MAGIC 2010

[Michael Fazio]

Marek,

		Woops! Forgot my own email subject! Silly me....

With regards to the type of middleware that I am searching for. Well,  
pub/sub with reliable and unreliable QoS is what we will most likely  
be using. I don't want to rush into a solution that buries the network  
in traffic from inter-broker communication, nor do I want to choose a  
middleware that fails in ad-hoc type networks. In any case, the  
middleware must hold up against repeated network partitioning and  
merging.

If we do use B.A.T.M.A.N we will likely be using the layer-2 flavor  
running on a router with openWRT. So drivers will not be an issue,  
just router selection.

I will be sure to share the tests if they occur!

Michael


On 15/03/2010, at 7:44 PM, Marek Lindner wrote:

>
> Hi,
>
>> Well I don't remember mentioning MAGIC 2010, but you are   correct,  
>> the
>> project is MAGIC 2010. Good investigatory work! :)
>
> the email's subject contained the necessary hints.  ;-)
>
>
>> Furthermore, message passing may not necessarily be done with the  
>> use of a
>> middleware. Realtime unreliable data such as GPS and telemetry  
>> information
>> may simply be pushed onto the network in UDP packets. I would  
>> prefer to
>> use a nice middleware that performs well in MANET environments and I
>> am still evaluating the possibility of this. If you have any
>> recommendations that would be good!
>
> What exactly are you looking for ("middleware" is a pretty broad  
> term) ? An
> application that can send GPS data through the network ?
>
>
>> Further on the topic of using BSS. We do expect wifi dead-spots and  
>> we
>> must absolutely try to minimize these. So the multi-hop nature of
>> something like B.A.T.M.A.N (i was hoping) would help in that regard.
>
> Yes, batman can help you "extending" the network. But the biggest  
> troublemaker
> will be the wifi driver because adhoc mode isn't that well  
> supported. 99% of
> the users want infrastructure mode, therefore developers work on  
> that first.
> Adhoc mode comes later (if at all), is often buggy and not well  
> tested. The
> wifi communities get around this issue by focussing on hardware  
> which either
> comes with an open driver (e.g. atheros chips) or have a working  
> adhoc mode
> implementation. Depending on how much freedom of hardware choice you  
> have I'd
> suggest you carefully pick your wifi chips.
>
>
>> I can't guarantee that we will use B.A.T.M.A.N but I will try to
>> evaluate it in the field eventually.
>
> Please, share the results of these tests with us. Even if you don't  
> choose
> batman we would be very interested to find out what we can  
> improve.  :-)
>
> Cheers,
> Marek
>

Re: [B.A.T.M.A.N.] B.A.T.M.A.N Suitability for MAGIC 2010

[Marek Lindner]

Hi,

> With regards to the type of middleware that I am searching for. Well,  
> pub/sub with reliable and unreliable QoS is what we will most likely  
> be using. I don't want to rush into a solution that buries the network  
> in traffic from inter-broker communication, nor do I want to choose a  
> middleware that fails in ad-hoc type networks. In any case, the  
> middleware must hold up against repeated network partitioning and  
> merging.

I'm not aware of any software which was specifically designed to operate over a 
mesh network (apart from mesh routing daemons of course). Everybody simply 
uses normal network operations and lets the lower layers handle the magic. 
Therefore they are all equally "bad" (unless someone can name a positive 
example)  :-).
If you are interested in QoS you should make use of the wifi's QoS as Linus 
suggested.


> If we do use B.A.T.M.A.N we will likely be using the layer-2 flavor  
> running on a router with openWRT. So drivers will not be an issue,  
> just router selection.

Ok.

Cheers,
Marek