Is there something conceptually wrong with this piece of code. I seem to be able to parse the start character and the sensor ID but I get no data bytes. x is all zeroes.
14
iRobot Create Open Inter face (OI) Specification
Stream
Opcode: 148
Data Bytes: N + 1,
where N is the number
of packets requested.
This command starts a continuous stream of data packets.
The list of packets requested is sent ever y 15 ms, which is
the rate iRobot Create uses to update data.
This is the best method of requesting sensor data if you
are controlling Create over a wireless network (which has
poor real-time characteristics) with software running on a
desktop computer.
• Serial sequence: [148] [Number of packets]
[Packet ID 1] [Packet ID 2] [Packet ID 3] etc.
• Available in modes: Passive, Safe, or Full
• Changes mode to: No Change
• Stream data byte 1: Number of packets requested
(0 - 43)
• Stream data bytes 2 - N: IDs of packets requested
(0 - 42)
The format of the data returned is:
[19][N-bytes][Packet ID 1][Packet 1 data...]
[Packet ID 2][Packet 2 data...][Checksum]
N-bytes is the number of bytes between the n-bytes byte and
the checksum.
The checksum is a 1-byte value. It is the 8-bit complement
of all of the bytes between the header and the checksum.
That is, if you add all of the bytes after the checksum, and
the checksum, the low byte of the result will be 0.
Example:
To get data from Create’s left cliff signal (packet 29)
and Virtual Wall detector (packet 13), send the following
command string to Create:
[148] [2] [29] [13]
NOTE: The left cliff signal is a 2-byte packet and the IR
Sensor is a 1-byte packet.
Create starts streaming data that looks like this:
header -> n-bytes -> packet ID 1 -> Packet data 1 -> packet id 2 -> Packet data 2 -> checksum
19 -> 5 -> 29 -> 2 (bytes) 25 -> 13 -> 0 -> 182
Checksum computation:
(5 + 29 +2 + 25 +13 + 0 + 182) = 182 and (256 & 0xFF) =0
I have not worked out the checksum computation yet. I am still a bit confused about that. In my particular code example, I am only streaming one packet which returns one byte in order to simplify things. I am sending BISC_SENSOR_CLIFF_LEFT (packet ID 9).
int Biscuit::biscCliff(int cliff) {
std::lock_guard<std::recursive_mutex> lock(s_mutex);
unsignedchar cliffbyte;
if(!biscSendByte(BISC_SENSOR)) return BISC_ERR;
switch (cliff) {
case 1 :
if(!biscSendByte(BISC_SENSOR_CLIFF_LEFT)) return BISC_ERR;
if(!biscReceiveByte(cliffbyte)) return BISC_ERR;
if (isNthBitSet(cliffbyte, 0))
return 1;
case 2:
if(!biscSendByte(BISC_SENSOR_CLIFF_FRONT_LEFT)) return BISC_ERR;
if(!biscReceiveByte(cliffbyte)) return BISC_ERR;
if (isNthBitSet(cliffbyte, 0))
return 2;
case 3:
if(!biscSendByte(BISC_SENSOR_CLIFF_RIGHT)) return BISC_ERR;
if(!biscReceiveByte(cliffbyte)) return BISC_ERR;
if (isNthBitSet(cliffbyte, 0))
return 3;
case 4:
if(!biscSendByte(BISC_SENSOR_CLIFF_FRONT_RIGHT)) return BISC_ERR;
if(!biscReceiveByte(cliffbyte)) return BISC_ERR;
if (isNthBitSet(cliffbyte, 0))
return 4;
}
return BISC_ERR;
}
So I am trying to get the streaming sensor way working. I tried the bump sensor first then switched to the cliff sensor as it was easier to pick up the robot than to kick the bumper repeatedly.
As a side effect to the start of the streaming process, single packet requests of sensor data returns corrupted values. I have to restart the program and the irobot create in order to restore the integrity of the serial read.
This is my output :
1 2 3 4 5 6 7 8 9 10 11
Cliff Stream Data received
Data 00000000
Got start byte
Cliff Stream Data received
Data 00000000
Got start byte
Cliff Stream Data received
Data 00000000
Got start byte
Cliff Stream Data received
This is the code that starts, reads, and pauses the stream.
1 2 3 4 5 6 7 8 9 10 11 12 13 14
if (tokens[0] == "cstream") {
std::cout << "Received command : Create Sensor Stream " << std::endl;
cout << "Press q to quit " << endl;
if (!robot.biscStreamStart())
std::cout << "failed to stream " << std::endl;
for (;;) {
if (waitKey(1) == 'q')
break;
usleep(1000000);
robot.biscStreamRead();
}
robot.biscStreamPause();
}