Maxbotics MB1013 Ultrasonic Not Reading Distance Correctly

Technical Programming
1

A few days ago I made a post regarding the usage of an analog ultrasonic sensor. I was informed that it’s too powerful to be used on the Analog ports via the roboRio and was suggested to use the KoP Ultrasonic Sensor.

Looking at the wiring diagram, and the constructor for the Ultrasonic class, it made sense to use the 2nd pin for communication, and obviously the 6th and 7th for power and ground.

The sensor is connected into DIO port 0.

It is constructed with…


//int pingChannel, int echoChannel
		ultrasonic = new Ultrasonic(1, 0);
		ultrasonic.setEnabled(true);
		ultrasonic.setAutomaticMode(true);

I tried 0,1, but received no values, and I receive values with 1,0 so I assume it is in the correct order.

To view the values, I’m using


ultrasonic.getRangeInches();

and displaying that on the SmartDashboard.

Here’s an example of the issue.
If I have my bumpers pushed up against a wall, I receive a value of 2 (normal according to the spec sheet). as I start to back away, the value will change from 3, to 25, to 2, to 15.

The sensor is mounted on a piece of lexan, just to the left of the bumper. I do not have a picture, but if needed I could draw something rather similar. If the sensor reads in a straight line, it should not pick up the bumper, but it is awfully close.

Perhaps it’s not wired right, mounted right, or constructed right, but if anyone knows the reason behind it, I would be more than grateful to hear it! Thanks!

2

Our read of the MB1013 datasheet says its operates 2.5v-5.5v.

We are running it off of one of the RoboRIO 5V analog ports, seeing 5V at 5M as documented, but things get a little gnarly below .4V/.4M (they claim .3V)

We wrote our own AnalogUltrasonic class, and are slowly bringing in the superclass and interface (SensorBase, PIDsource and LiveWindowSendable) (why doesn’t Java have multiple inheritance???) aspects to make the class more useful and easier to display on the dashboard.

We’re not slamming into our (simulated) airship, so far so good. The MB1013 on the bagged 'bot is closer to the outside, so we may need the collision sensor in the NavX to save the field :slight_smile:

3

We also use the kop sensor and and analog port on the robrio. The sensor will have some lag if you are moving, so you need to anticipate that, and will have some noise that will affect readings.

We sample 12 readings, and toss out the two max, and the two min values and then avg the remaining 8. This adds to the lagging, but gives a more stable distance calc.

4

Hey, so since you’re trying to use ultrasonic sensors, I thought I’d like to share some of our experiences. You’re using Maxbotics (those are the best ones to use, in my opinion) but they have several models to choose from. I would personally recommend the 1340 models (trust me, we spent a LOT of time comparing data sheets and have an essay we wrote to convince our treasurer to approve of the purchase if you want it)-- they have the most narrow beam (we found that most of the other models, including the one in the KoP, were prone to reading the ground instead of the target due to their wide beam), and also have an incredibly high resolution. As for your concern regarding accuracy, its really best if you make your own class. Extend the AnalogInput class, use getVoltage and put the values on your dashboard, take out a ruler, and start calibrating until you figure out how to convert the value to inches. Also, another team previously mentioned this, but I would highly, highly recommend taking multiple samples. We overloaded our getInches method that we made, so that one would return the current inches, while the other would take 64 samples (which seemed to be enough to be accurate and not too much to lag the robot) and average them, and then return that value.

Although, some warning-- ultrasonic sensors are finicky. We had a host of issues in the beginning, one of which was the motors radiating EMF signals which interfered with the sensors. It took us a while to find, but we ended up resolving it by encasing our wires in aluminum foil (and then later switched to copper tape). And once we finally got the sensors to work, we got side auto 10/10 times-- in laboratory conditions. At our first tournament, it ended up working perhaps once the entire tournament. Every other time we ended up with wildly inconsistent results.

If you get yours to work properly at a tournament consistently, however, we would love to hear about it. I’m not ready to give up on the sensors just yet.