使用 ToF 距离传感器从处理上的 USB 端口传输数据

Question

I'm trying to get the distance of the sensor on Processing but when I output the calue in the console I'm only able to see ASCII text. How shoudl I proceed here?

import com.hamoid.*;

// Example by Tom Igoe

import processing.serial.*;

float angle = 0;
int myString;


Serial myPort;  // The serial port


void setup() {

  size(500, 500);
  // List all the available serial ports
  printArray(Serial.list());
  // Open the port you are using at the rate you want:
  myPort = new Serial(this, Serial.list()[3], 115200);

}

void draw() {
  background(0);
  // Expand array size to the number of bytes you expect
  byte[] inBuffer = new byte[4];



  while (myPort.available() > 0) {
    inBuffer = myPort.readBytes();
    myPort.readBytes(inBuffer);
    if (inBuffer != null) {
      String myString = new String(inBuffer);
      println(myString);


    }
  }

}

this is what I see when I run the code:

T�T� T�T� T�T� T� T�T� T�T� T�T� T�T� T�T� T�T� T� T�T� T�T� T� T�T� T�T� T�T� T� T�T� T�T� T� T�T�

Answer 1

Let's try the obvious stuff and work our way from there.

You have 4 bytes, which means 32 bits. That's awfully close to a 32 bits integer, especially other things hints at an integer. The only bad new here is that we don't know if it's really an integer, and even if it is, we still don't know if it's a signed integer or a unsigned integer.

First thing to try: we're using java, and java considers byte as a signed type. Let's cast it to an integer right off the bat:

// #1
if (inBuffer != null) {
  int distance = inBuffer;
  println(distance);
}

Alternatively, we may have some success with one of Byte's methods (it's basically the same operation, but we never know):

// #2
if (inBuffer != null) {
  int distance = inBuffer.intValue();
  println(distance);
}

Maybe it's unsigned, now. The difference lies in the fact the the sign (plus or minus, as in "this number is less or more than zero) takes bits, while with an unsigned number all the bits can be used to stock part of the number rather than the sign. You would have to cast it to "ignore" the sign, like this:

// #3
if (inBuffer != null) {
  int distance = (inBuffer & 0xFF);
  println(distance);
}

Start with #1 and then #3. I'm betting on #3, since there's no need for negative distance on a sensor. Let me know what you find!

==========================================================

Here's a primer on binary numbers. (spoilers alert: binary is awesome)

As you probably know, a binary number is composed of 1 and 0. Nothing else. And, as you may or may not know, that's the kind of stuff which our whole society is based upon. This, and operators. But let's stick to binary.

When reading binary, you have to read from right to left. I mean, if you're a cyborg or something you can probably just translate it more easily, just like we know that 5 000 000 is five million by reading it normally. But to really know how much the "5" is worth in "5 000 000", you have to start reading from the right, or else you don't know how many zero follows it - then it could mean anything.

That's the same with binary, except that with decimal each number on the left is worth 10x more than the last, while in binary it's 2x.

In binary, first number on the right is worth 1. Every other number is worth twice the previous one. So, for one byte, the values of the "ones" are as follow:

128 64 32 16 8 4 2 1
 1   1  1  1 1 1 1 1 == 255
 1   0  0  0 0 0 1 0 == 130
 0   0  0  0 1 1 0 1 == 13

That's a simple addition (just like any number when you think about it). It looks complicated, but it's easy once you get the idea.

A byte is always 8 bits. Like these examples:

[00000000] == 0
[11111111] == 255
[00001101] == 13

Now, if we look at the specs for your sensor, we find these 3 informations:

8 data bits
no parity bit
one stop bit

Which means the following:

1. The data will be contained in bunches of 8 bits (one byte).
2. There is no bit reserved for error detection
3. One special bit will tell when communication starts or ends.

We still don't know if the data will be signed or unsigned (spoiler alert again: probably unsigned), but we already start seeing patterns here. Even in the strings you obtained, we can detect a clear pattern:

84 6 177 84 6 194 177 84 6 189 203 84 6 194 177 84 6

Problem is, these are probably not integers. They are binary interpreted as integer by the machine. That's not the same.

Your sensor is "free running", which means that it's never waiting for you. It's always sending signals. Every time it's finished sending a number, it starts sending another one, all the time. This could explain why you get this kind of loop in your data.

Now, if we go into more details, we can see that your sensor's protocol isn't exactly just "sending distances". It's more complex than that. Here's how it works:

1. It starts with one byte containing a 7 bits address and a 0 (the "write bit"). That's probably what you read as "6".
2. It sends another bit with the address, but with a "1" at the end (the "read" bit"). That's probably what you read as "84".
3. It sends 2 bytes of data containing a 16 bits number, which is your measurement in mm.
4. It sends a checksum (one byte).

That would make sense. After all, your sensor is supposed to be read in millimeters, and could reach up to 60 000 mm, which is not possible in only one byte (which tops at 255, remember?). In fact, you can't write 60 000 in binary with less than 16 bits.

Now, how do we interpret these?

First thing, port.read() reads only one byte at a time, so it cannot read 16 bits in one go. That's one of the reasons the numbers you get makes no sense (8 bits only range from 0 to 255, so you cannot get a higher value either).

Instead of trying to get a number right away, let's see if we can calculate the real values behind your current inputs by throwing them back into binary:

194 == [11000010]
177 == [10110001]
[11000010 10110001] == 49 841


189 == [10111101]
203 == [11001011]
[10111101 11001011] == 48 587

Were you pointing it at something about 5 meters away? Would that make sense?? Try pointing the sensor toward something which you know the approximative distance and let's do this again, just for fun! And science!

Answer 2

@laancelot I've used this sketch and I'm getting integers now, but not the right ones. Eg below:

84 6 177 84 6 194 177 84 6 189 203 84 6 194 177 84 6

This is the sketch I'm using on processing:

    import com.hamoid.*;

// Example by Tom Igoe

import processing.serial.*;

int distance;

Serial port;  // The serial port

void setup() {

  printArray(Serial.list());
  // Open the port you are using at the rate you want:
  port = new Serial(this, Serial.list()[3], 115200);

}

void draw() {
  if (0 < port.available()) {  // If data is available to read,
    distance = port.read(); 
  }
    println(distance);
}