I’m teaching a Vex programming class next week. For this class I’ve built 5 identical clawbots from new kits and added several sensors, including the ultrasonic sonar.
On 3 of the robots, the sonar works fine. On 2 of them, the readings are stuck at 5cm.
Details:
New Vex Cortex clawbot kits
New “Programming” add-on kit
RobotC 4.10
The sonar is plugged into digital ports 3/4 and configured for sonar-cm
I’ve done this testing on both of the “stuck at 5cm” bots:
covering either port on the sensor causes the reading to go to 65535 (infinite)
placing an object closer than 5cm gets a correct reading, e.g. 4cm or 3cm
placing my finger as an audio barrier between the two ports appears to cause the sensor to start working correctly.
I’ve rearranged the wires and checked their connections and they don’t appear to be getting crosstalk or noise on the wires.
I’ve swapped around sensors and robots and the problem appears to be combinations of specific parts. One combination will work correctly, but those same parts paired with other parts exhibits the 5cm symptom. This applies to both the sensor and the Cortex! This is really weird.
Yes, I’m sure that there aren’t any objects in front of the sensor during testing.
My working theory is that the emitter is too loud or the receiver is too sensitive so it always “hears” the pulse just in the ambient air before it has a chance to echo off a real surface.
Questions:
Is this a common fault? I’ve never seen this kind of behavior before.
If this is a known problem, what’s the solution? I need something before next week.
Not a problem I’ve heard of before, it’s usually more black and white, work or not work.
Do you have other sensors plugged in?
Try ports other than ports 3/4, for example 7/8.
Are you testing one robot at a time, if all 5 sonars are on there is the potential for interference, however, I would not expect a 5cm reading even in that situation but rather random results. A reading of 5cm implies the ping is detected very quickly, your “audio wall” solution is interesting, do you see any physical damage to the sonar? Ar you saying that a sonar that does not work on one robot will work on another? How high off the ground is the sonar? Does changing the mounting position help? (ie. is it picking up reflections from the floor).
Yes, I have lots of stuff plugged in. There’s only one open digital port.
Analog:
1 - potentiometer
Digital:
1&2 - bumper sensors
3/4 - sonar
5 - limit switch
6-8 - LEDs
9
10-12 - LEDs
I’d considered moving the sonar to another port pair, but was resisting since that’d mean moving something else and ultimately reworking all the bots. Before diving in, I wanted to ask here if there are any ports that are known to be more/less sonar friendly than any others.
The sonar is mounted horizontally front and center on the standard clawbot. So perhaps 3cm above the floor. I was testing on carpet, but also tilted the bots toward the ceiling to ensure they had a clear view of empty room. This had no effect on the 2 problem bots. And the 3 working bots always ignored the carpet.
Yes, I’m testing one robot at a time. The procedure is:
boot the robot
connect the programming cable to the remote & wait for VEXnet link
download the code from RobotC and wait for debugger to come up
view the Sensor tab in the RobotC debugger to see the live value from the sonar
while viewing the live sensor value, reorient the robot and adjust what it can “see” to figure out what’s affecting the ping return.
All 5 sensors are new out of the box and have never seen prior use. When I first saw the problem on one bot, I carefully inspected the sensor for damage, but none was obvious. When I got a second sensor with the same behavior, I got suspicious that something stranger was in play and started a deeper investigation.
The strangest part of the investigation was swapping sensors around to follow the trouble (standard troubleshooting technique). I did that for 2 sensors/bots and I found that only one combination that worked correctly. All others showed the problem:
bot 1 - sensor 1 - works normally
bot 1 - sensor 2 - problem
bot 2 - sensor 2 - problem
bot 2 - sensor 1 - problem
This doesn’t make any sense to me.
I have more time tonight and will re-run the tests, expand the set of tested elements, and observe if I’m in some way influencing the outcome. I think I controlled for interference pretty well last night, but we’ll see.
I am open to suggestions and was hoping that somebody had seen and dealt with something similar already.
Ports 4 and 10 have issues, they share an interrupt. When there is an LED on port 10, ROBOTC will configure that as an output and can screw up port 4 sometimes. Try swapping the bumper switches on ports 1&2 with the Sonar and see what happens. Or (simpler) move the LED on port 10 to port 9 and have port 10 as unused.
Ah, that’s exactly the kind of information I was looking for. For my first test tonight, I was going to move the sonar to 1/2 since that was the easiest swap. Sounds like that should help.
I intentionally have the LEDs in 2 groups of 3, so the gap at 9 is on purpose. If I need to shift anything there, I’d close the gap at 9 and open one at 6. But that leaves 10 in use.
Thanks so much for the port 4/10 info. Are there any other shared ports I need to be aware of? Or is it just 4 and 10? Is this all documented anywhere? (Edit: just saw your addition of references. Am reading now.)
Terry
ps. you wouldn’t happen to know anything about mis-behaving IMEs? I also have some of those on one bot. They blink like they’re enumerated correctly, but never count anything. They were working for a while, now they’re getting fussy again. If you have any ideas, please pick up this thread: http://www.robotc.net/forums/viewtopic.php?f=11&t=8973
It is sort of documented but is not pushed front and center so you have to know where to look and what to search for.
Some devices that cause an interrupt.
Sonar - the input
Red quad encoder
So having quad encoder on ports 3&4 and also 9&10 does not work. Generally ROBOTC will turn of the 3&4 pair if you try and use 9&10, don’t think there is any warning of that behavior though.
[IME - Technical description and software workarounds
But start by checking the cables are installed well, they need quite a good push to get them into the IME. Debug one cable/IME at a time and see if you can find one bad part causing a problem for the whole system.
I tried moving the sonar to ports 1/2, but that didn’t make any difference.
Nor did starting with a blank program and enabling only the sonar on either ports 1/2 or ports 3/4.
I tried pointing the sensor every which way, but that didn’t help either.
The fix I found was to put a Post-It in between the emitter and detector. I’ve attached a photo. After I did this, it worked just fine.
I’d really love a different solution (i.e. more robust), since a Post-It is unlikely to survive the rigors of competition even if it were competition legal.
In the photo it looks somewhat close to the floor. Any chance it might work better if lifted a little or use washers or something to help tilt the sensor up slightly?
Also, have you tried to run it on something other than a carpeted floor? I know it’s summer, but maybe some static electric charge could be building up on that carpet??? In the winter, these robots can build up quite a bit of charge even on the field pads. Just a thought.
So is the problem specific to one sensor? Seems like it must be damaged in some way, I’ve never had a problem, mounting position shouldn’t be a problem. I’ve often mounted them that low (well, not quite that low), for example.
I would like to get a scope on the signals to see what’s going on, any chance you are near Los Angeles?
Do you have this same problem if the sensor is not screwed onto a frame? Looking at your photo again, I’m wondering if the way you have it mounted might be warping the grey plastic frame of the sensor, perhaps causing some kind of internal misdirection of the ultrasound beam.
If so, perhaps try putting some washers behind the sensor where the mounting screws are located so that the sensor frame can’t be warped when you tighten the screws. I’m just thinking out loud.
The beam should be wide enough to avoid problems caused by sensor misalignment, but this is also what came to my mind first…
The devices are so simple that I would be very surprised if it were a hardware problem (caused by damage, but I could believe a manufacturing issue). Definitely try it with no other sensors plugged into the Cortex to rule out an interrupt interference problem. If you’ve got another ultrasonic, try that one as well to rule our a Cortex hardware problem or a software problem.
Recap of the facts:
[LIST]
*]- I have 5 identical robots built from new kits. Each has a sonar mounted in the same place.
*]- 3 of the sonar sensors behave as expected (no false readings)
*]- 2 of the sonar sensors detect fixed false echos (i.e. always report 5cm) when pointed at clear space
*]- moving the sensor to a different set of digital ports, thus using a different interrupt did not affect the behavior
*]- reorienting the robot so it had a clear view of empty room (not near the floor) did not affect the behavior
*]- unmounting the sensor did not affect the behavior (even if the tabs were slightly warped when mounted, it’s definitely flat when unmounted)
*]- the false readings are apparent from the moment the bot is switched on. The echo test is done without driving the bots (that, coupled with the humidity at my house tend to rule out static buildup)
*]- blocking either port causes a “no-echo” reading (the false echo is definitely a product of sound exiting the emitter port and re-entering the detector port. No internal leakage)
*]- both of the sensors getting false readings were “fixed” by adding the Post-It wedge between the ports
[/LIST]
The last fact is the crucial one. Nothing besides adding the paper wedge affected the behavior in any way.
My working theory is that the design of the emitter/detector pair must run pretty close to the edge of false echo in order to achieve maximum sensitivity to distant objects. Production tolerances could sometimes produce sensors that cross the line. I’d think these would be caught in production screening, but it’s possible that I just got lucky and had a 40% defect rate in my order (2 of 5).
JP: Yes, I live in Long Beach and work in Irvine. Would either of these be convenient for a meeting?
Sounds like you should contact VEX tech support if these are new parts.
I’m about an hour away from there in the Glendale/Pasadena area. Are you running the programming course at a school or as part of a summer camp? Is this connected with a VEX team?
I was starting to think that myself. I’m glad I had a chance to discuss it with the group and make sure it wasn’t something I was doing.
I’m teaching the class as part of a summer camp for my wife’s non-profit. This is our first Vex class. (We’ve been doing LEGO NXT and EV3 for many years)
My schedule is pretty full between now and the class (18-20). There’s a possibility I could drop by your place on Saturday the 23rd if that works. PM me to work details.
