Filtering noise coming from robot

[Rap_Master_T]

Hi,

We're trying to build a VI using occupancy grid map and a robot to map a room. In order to do so we need to change the coordinates in the map according to encoders values which we read from the robot. The new location determines what will be the robot's next velocity and steering angle. So we're sending the robot 2 commands all the time ("Read encoders values" and "Set velocity and steering angle"). Problem is- when we switch between the two commands we get a lot of noise (actually it happens also if we change only the velocity or steering angle). We're using one VISA port to communicate with the robot. Any idea what can we do to filter this noise? Is this a known problem?

Thanks

[johnsold]

What kind of noise are you getting? What signal is it on?  Give us more details including some clean and noisy data.

The way your post reads, it almost makes me think the robot is screeching its tires when you change velocity or angle (= acceleration).

Lynn

[Rap_Master_T]

As I said, I'm using 2 commands:

1. Set velocity and steering angle- the format of this command is "04[byte][byte]" when the first byte determines the velocity and the second determines the steering angle.

2. Read encoders values- the format of this command is "07" and the response from the robot is the encoders values for each of the wheels (4 bytes to each wheel, 6 wheels total).

In our VI we're using a loop and in each iteration we send to the robot "set velocity and steering angle" and then (after delay) we send "read encoders values" and update the robot's coordinates according to the encoders values.

The expected response from the robot should be: "07[4 bytes for wheel 1][4 bytes for wheel 2][4 bytes for wheel 3][4 bytes for wheel 4][4 bytes for wheel 5][4 bytes for wheel 6]. But whenever changing the velocity or steering angle we get noise for few iterations (response in varied length- not the expected number of bytes, not getting 07 in the beginning of the response). This noise damages the robot's ability to map the room correctly and the map which is created doesn't look like the room.

We thought of 2 ways to solve this issue:

1. Try to make the loop iterations much shorter so the error's effect would be less significant

2. Try to filter the noise- we are using now a simple filter whichr replaces values which are much bigger than expected with 0, but still the results aren't good enough.

So our question is if this is a known problem and is there any solution we can use to overcome it?

I'm attaching our VI, the relevant part (communicating with the robot) is in the bottom of it.

Thanks  a lot

[BillMe]

What kind of serial port are you using? Are you sure this isn't a hardware problem on either end of the interface such as poor or missing shielding/grounds? Does the noise coincide with the motors moving/turning?

[Rap_Master_T]

The serial port is RS-232. We're not sure it's not a hardware problem. How can we verify it?

The noise indeed coincide with the motors turning/accelerating (the motors move all the time)

[BillMe]

Single ended unshielded lines (such is common with RS232) are very susceptible to noise. And motors are notorious for generating it, particularly if the interface electronics are not isolated well from the motor electroncs. Make sure the cable has both grounds connected, pin 1 to pin 1 (ground), and pin 7 to pin 7 (signal ground).

[johnsold]

One obvious problem with your code (in addition to the bloock diagram being six times too big to fit on one screen) is that you are using Bytes at Port with termination characters enabled. If any of your data bytes ever have the value 10 (hex A, or Line Feed), the read will end. The next read will get part of the first message and part or all of the next message.  If your robot sends termination characters, use them and get rid of the Bytes at Port. If it does not send them, then disable them at Configure Serial Port.vi.  Your description of the effects of the "noise" sound very much like this kind of situation.  Try putting an indicator on the error out of the VISA Read that gets the data from the robot. VISA Read issues warnings in some situations which will not be reported by the Error Handler.

Fix this and let us know if you still have the "noise" problem.

Lynn

[Rap_Master_T]

Hi Lynn,

Sorry for the late reply. We were busy lately,

Any way, Thanks for your solution. It really seems to help. We disabled the terminating characters so most of the reads from the robot are OK. Another issue we see is that in some of the reads the last byte "disappears" and we don't understand why. Any idea what could be the reason?

[johnsold]

When the last byte disappears, it may be due to an extra byte at the beginning. I did not go back and study your VI carefully. Does your protocol specify a constant number of bytes? Does the robot only transmit when you send it a command? One way to see non-printable characters is to make the read string indicator use '\' Codes Display. Then it will show all characters received. Any nonprintable characters will show up as \hex characters.

Lynn