lithium flowers bloom » xbee

Communication Setup for Blinded

L.J — Sat, 15 May 2010 20:52:00 +0000

Li and I worked on a group of robotic/kinetic creatures to create an ironic and self-balanced networked system called Blinded.

A very detailed documentation of the construction iterations are up on Li’s website, so I’ll just write a bit about the communication between the creatures.

For the first iteration we had only one creature fully assembled so I built a quick “single character communication protocol” that allows the creature to be remotely controlled from a computer. I have two pre-paired series one xbees which are perfect for this basic cable replacement purpose.

The arduino on the creature side is expecting specific “single character” functions from the serial channel via xbee, available instructions are:

1. L – turn left
2. R – turn right
3. F – step forward
4. anything else – stop

At the same time, for monitoring purpose the arduino is reporting if the creature is on its target by comparing its left and right sensors and their historic readings, the reported status is written into the serial channel simply with notation of 1 (on-target) and 0 (target lost).

Because we had only one creature ready back then, the pursuing status is not entirely making sense, so the computer mainly served as a remote controller. The controller setup is pretty simple though, it can be just an xbee explorer board and any serial terminal program can be used to send commands to the remote creature. Following video shows one of our field tests in the park.

After more creatures were added to the group, the situation became much more complicated and I have to put up a processing sketch to coordinate input from multiple creatures. I did not use the xbee library for processing although it did look pretty promising in the examples and taking care a lot of the heavy liftings. But I dig into the source code a little bit and got a feeling that it might be a pain to use with series 2 xbees. So I just wrote some very simple parsing functions to take apart I/O packets and make sure I have access to any digital or analog pins without too much hack.

For physical setup, I switched all remote xbees to series 2 and put their firmware to router-at mode. The base station that stays with the computer is in coordinator-api mode. I used 4 pins of the remote xbees, 2 for digital output (remote commands), 2 for analog input (transferring sensor values to the remote computer/coordinator). Each remote xbee will still need to handle status reporting and command receiving, and the arduino on the creature remains as local intelligence that parses the sensor information and actually controls the motion.

Commands for Xbee configuration:

ATD04
ATD14
ATD22
ATD32

During runtime, the computer is able to set the remote xbee digital pin state through processing sketch. Code snippet for setting

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

void setRemotePin(byte []address, String command, int value)
{
if (address.length != 8)
{
println("invalid address");
return;
}
if (command.length() != 2)
{
println("invalid command");
return;
}
serialSelector.port.write(0x7E); // start byte
serialSelector.port.write(0x0); // high part of length (always zero)
serialSelector.port.write(0x10); // low part of length (the number of bytes that follow, not including checksum)
serialSelector.port.write(0x17); // 0x17 is a remote AT command
serialSelector.port.write(0x0); // frame id set to zero for no reply
// ID of recipient, or use 0xFFFF for broadcast

for (int i = 0;i < 8; i++)
{
serialSelector.port.write(address[i]);
}

/* broadcast */
/*
serialSelector.port.write(00);
serialSelector.port.write(00);
serialSelector.port.write(00);
serialSelector.port.write(00);
serialSelector.port.write(00);
serialSelector.port.write(00);
serialSelector.port.write(0xFF); // 0xFF for broadcast
serialSelector.port.write(0xFF); // 0xFF for broadcast
*/
// 16 bit of recipient or 0xFFFE if unknown
serialSelector.port.write(0xFF);
serialSelector.port.write(0xFE);
serialSelector.port.write(0x02); // 0x02 to apply changes immediately on remote
// command name in ASCII characters
serialSelector.port.write(command.charAt(0));
serialSelector.port.write(command.charAt(1));
// command data in as many bytes as needed
serialSelector.port.write(value);
// checksum is all bytes after length bytes
int sum = 0x17 + 0xFF + 0xFE + 0x02 + int(command.charAt(0)) + int(command.charAt(1)) + value;

for (int i = 0;i < 8; i++)
{
sum += address[i];
}

serialSelector.port.write( 0xFF - ( sum & 0xFF) ); // calculate the proper checksum
//delay(10); // safety pause to avoid overwhelming the serial port (if this function is not implemented properly)
}

Sensor Network: Data Logging and Visualization

L.J — Mon, 01 Mar 2010 07:50:18 +0000

I’m working with Sebastian and Michael as “visualization” team for the sensor network assignment for this week’s Sociable Objects Workshop. It’s very challenging for the whole class to work on one single project, but so far it went on pretty well. Tasks are split and assigned and we also find ways to work with dependencies and such constraints.

Since we are just focusing on the visualization part, meaning that we take on only after all the data are aggregated at the coordinator xbee, our main effort will be data logging, mining and visualization. So the first thing we built is a pseudo data generator that feeds data in the same format as the data will be from the coordinator. We talked to the base station team and agreed that we will be getting raw API I/O RX packet and we will take care of the parsing and data storage.

I put together some simple arduino code to feed pseudo data, they could be easily replaced by a real coordinator and ideally we will not have to change the processing code on the other side which is listening to the serial channel.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91

#define ADDRESS_COUNT 9
int addresses[9] = {
0x0001,
0x0002,
0x0003,
0x0004,
0x0005,
0x0006,
0x0007,
0x0008,
0x0009,
};

void setup()
{
Serial.begin(9600);
randomSeed(analogRead(0));
}

void loop()
{
for (int i = 0;i < ADDRESS_COUNT;i++)
{
if (random(1000) > 990)
{
if (random(1000) > 500)
{
sendPseudoPackage(addresses[i], 1);
}
else
{
sendPseudoPackage(addresses[i], 0);
}
}

}
delay(50);
}

void sendPseudoPackage(int address, int value) { // pass either a 0x4 or and 0x5 to turn the pin on or off
Serial.print(0x7E, BYTE); // start byte
Serial.print(0x0, BYTE); // high part of length (always zero)
Serial.print(0x17, BYTE); // low part of length (the number of bytes that follow, not including checksum)
Serial.print(0x92, BYTE); // 0x92 is I/O RX Packet

//05-12: 64-bit address
Serial.print(0x00,BYTE);
Serial.print(0x13,BYTE);

Serial.print(0xA2,BYTE);
Serial.print(0x00,BYTE);

Serial.print(0x40,BYTE);
Serial.print(0x33,BYTE);

int low = address & 0xFF;
int high = (address - low) >> 2;

Serial.print(high, BYTE);
Serial.print(low, BYTE);

//13-14: 16 bit of recipient or 0xFFFE if unknown
Serial.print(0xFF, BYTE);
Serial.print(0xFE, BYTE);

//15: Receive Option
Serial.print(0x01, BYTE);

//16: Num Samples
Serial.print(0x01, BYTE);

//17-18 Digital Channel Mask
Serial.print(0x00, BYTE);
Serial.print(0x01, BYTE); //only Digital I/O 0

//19: Analog Channel Mask
Serial.print(0x00, BYTE);

//20-21: Digital Samples
Serial.print(0x00, BYTE);
Serial.print(value, BYTE);

//no analog samples

// checksum is all bytes after length bytes
long sum = 0xFF; //fake
Serial.print( 0xFF - ( sum & 0xFF) , BYTE ); // calculate the proper checksum
delay(10); // safety pause to avoid overwhelming the serial port (if this function is not implemented properly)
}

Then I wrote a basic processing sketch which filters the data and stores only changes to the databases. The sketch itself servers as some sort of realtime visualization on the input, and we get a feeling of how often data are changing and potentially detects sensor failures if one sensor is not active for a very long time.

The processing sketch is sending data to a website that handles data logging. The website also provides query api that returns sensor history in json format, and functions like filtering by certain address. The site itself is lightweight and fairly easy to add new functionality.

The plan is to meet tomorrow and start building a web interface upon the api for the final visualization. Hopefully we could also get to verify if the pseudo data is identical to the real format, and maybe we can get a test run with the real setup.

~~Stay tuned!~~

UPDATE: A list of available API functions:

url: http://itp.nyu.edu/~lx243/sensornet/index.php/api/

all (meaning that the url will look like http://itp.nyu.edu/~lx243/sensornet/index.php/api/all)

returning all records in json format

find/:address

returning all records from address specified
address should be a string of 64bit address, e.g. 0013A20040330001

find_today/:address

find_by_day/:address/:day

day should be in the format of yyyymmdd, e.g. 20100301

status/:address

returning latest records from specified address

status_at/:address/:time

returning latest records by the time specified
time should be in the format of yyyymmddHHMMSS, e.g. 20100301140000

changes/:address

returning all changes at specified address

changes_today/:address

returning changes happened today at specified address

changes_by_day/:address/:day

returning changes happened today on specified date at specified address
day should be in the format of yyyymmdd, e.g. 20100301

stats/:address

returning open time, close time, changes, and total active time of the sensor

stats_today/:address

returning above stats from specified address

stats_by_day/:address/:day

returning above stats from specified address on specified day

UPDATE 2: Visualization

It took a while for Sebastian and I to make processing.js to talk to the API and get real time update. We used jQuery as a bridge to retrieve the data and feed it on the page to processing.js. But eventually all is fine:

Using XBee Without Arduino

L.J — Sat, 27 Feb 2010 04:34:04 +0000

I worked with Adi on the “Romantic Lighting Sensor” Lab for Sociable Objects Workshop. Since we do not have a photo cell at hand, we just used a normal potentiometer as the remote sensor. The code is from Rob Faludi’s course code sample page.

We had some problem at first with the receiver side and we didn’t find an effective to debug it. It was pretty clear that the transmitter is working fine since while I was using just xbee explorer board as receiver I can directly see the data coming from the serial channel. However I cannot get the code to work when I plugged the xbee back to arduino circuit.

I ended up using a processing sketch to print out serial data from arduino since I cannot see it directly by printing out data to the serial terminal in arduino code. So lesson learned:

1. the resister used to augment sensor output value to fit xbee’s 3.3v requirement has to be carefully handled, otherwise you do not get to use full range of the sensor output and it makes it harder to figure out the range to look for in the receiver code,

2. a processing sketch is necessary for debugging. it gives a lot of confidence while you can see what is in the data stream, at least for me.

simple remote xbee sensor

with feedback

Sociable Objects: a nap doorbell

L.J — Mon, 15 Feb 2010 22:07:33 +0000

Nap doorbells are designed for nappers. They will not actually ring and wake you up unless it is a real emergency. This project is developed in collaboration with Adi and Asli.

Doorbell for insistent visitors from My Journey on Vimeo.

Switch Code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

int BUTTON = 2;
int GREEN = 12;
int RED = 13;

void setup()
{
pinMode(BUTTON, INPUT);
pinMode(GREEN, OUTPUT);
pinMode(RED, OUTPUT);
Serial.begin(9600);
}

void loop()
{
if (digitalRead(BUTTON) == HIGH)
{
Serial.print('D');
delay(10);
}

if (Serial.available() > 0)
{
char r = Serial.read();
if (r == 'G')
{
digitalWrite(GREEN, HIGH);
}
else if (r == 'R')
{
digitalWrite(RED, HIGH);
}
}
else
{
digitalWrite(GREEN, LOW);
digitalWrite(RED, LOW);
}
}

Buzzer Code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72

int BELL = 5;
long lastReleased = -1;
long lastPressed = -1;
int counter = 0;
int offcounter = 0;

boolean pressed = false;

void setup()
{
pinMode (BELL, OUTPUT);
Serial.begin(9600);
}

void loop()
{
if((Serial.available() > 0))
{
if (Serial.read() == 'D') // look for a capital D over the serial port and ring the bell if found
{
//Serial.println("ON");
if (!pressed)
{
lastPressed = millis();
pressed = true;
long interval = lastPressed - lastReleased;

//Serial.print("+");
//Serial.println(counter, DEC);
//Serial.println(interval);

if (interval < 1000) // if this one is pressed soon enough, increase the counter
{
counter++;
}
else
{
counter = 0;
}
}

//send feedback that message was recieved
if (counter >= 5)
{
Serial.print('G');
//ring the bell briefly
digitalWrite(BELL, HIGH);
delay(10);
digitalWrite(BELL, LOW);
}
else
{
Serial.print('R');
}

offcounter = 0;
}

}
else
{
//Serial.println("OFF");
offcounter++;
if (pressed && offcounter > 5000)
{
pressed = false;
Serial.print("-");
lastReleased = millis();
offcounter = 0;
}
}
}