Close

Messaging formats: what should be sent to who?

A project log for Elephant AI

a system to prevent human-elephant conflict by detecting elephants using machine vision, and warning humans and/or repelling elephants

neil-k-sheridanNeil K. Sheridan 09/20/2017 at 18:040 Comments

So, I've been deciding which format we should use to store the observations made by the detection devices, and for 'on the wire' message format per communications between detection devices, deter devices, web server, twitter, mobile phones. 

Let's look back at the system architecture:


We are going to be sending messages to:

1. Elephant deterrence devices (full message)

2. Web server (full message)

3. Mobile phones (SMS, so just some fields extracted from message)

4. Twitter DMs (full message)

Here's what I've got in XML for the message format:

<elephantalertmessage>
 <spotted></spotted>
 <location></location>
 <latitude></latitude>
 <longitude></longitude>
 <date></date>
 <time></time>
 <batterystatus></batterystatus>
 <spottingdetails>
   <herd></herd>
   <lonemale></lonemale>
   <calves></calves>
   <tusks></tusks>
   <musth></musth>
 </spottingdetails>
<deter>
  <performdeter></performdeter>
  <audiodeter></audiodeter>
  <physicaldeter></physicaldeter>
 </deter>
</elephantalertmessage>

 I know I've written it in XML, but I might go ahead and use JSON instead - since that's a lot easier to work with in python. I'll see how I go on. I didn't get on too well with XML today!

Anyway so, either XML or JSON can be stored as file after we finish we detecting and get all our variables back. 

<performdeter> would be determined for each device and hard-coded in by the users. For instance, if there was no deter device nearby we wouldn't want true for this. And if it was an elephant path we wouldn't want deter to be true! However, a crop field placed device would want this value as true.  Same kind of thing for deter type i.e. <audiodeter> and <physicaldeter>

The <location> is tricky. There are several ways to approach this:

- Simply device number is reported. Here system users would have to recall from memory where this device resides (" oh yes number 10 is on the elephant path near to where they exit the forest") if the message is coming via SMS. If it's coming via device -> server -> mobile gateway -> mobile phone then we could have a lookup table on the server. This would match device numbers to Lat/Lon physical locations. The lat/lon can be given to Google Maps API to provide users with a map showing the location. In this scenario, users would have to update the lookup table whenever devices were moved.

- Each device has a GPS. In this scenario we can include the <latitude> and <longitude> in messages via SMS and via device -> server -> mobile gateway -> mobile phone, or device -> 3G/4G -> twitter DM. Obviously giving a lat/lon via SMS e.g. Lat=19.075984, Lon=72.877656 is not going to be very helpful!  But we can go ahead and use the Google Maps API to give mapping if we are sending this via the device ->  server -> mobile gateway -> mobile phone pathway. So the main advantage of each device having GPS is that we don't need a lookup table and system users don't need to worry about updating such a table themselves. They can move the devices around as they wish.

To be honest, maybe it is getting a bit over-complicated. A lot of the time I think we will have a low-connectivity scenario, so we'll only be having SMS available. We could actually make the <location> a bit more useful by keeping the devices static and having a string for each that we put into location e.g. "this is the one at top of Aadesh's biggest field near the forest" or "this is the one on the elephant path when they exit forest to reach the water".

So we'd parse the following from XML/JSON we made, for sending out via SMS:

<spotted>

<location>

<date>

<time>

<spottingdetail>

<deter>

<batterystatus>

___

Just a note, that I'm thinking of after we've triggered a deter device! Should the deter device message the detect device and say done=true, then detect device can be thinking if we didn't get another <spotted> as true within 360s then deter was successful!

Discussions