We’re trying to get our Romi to read an Ultrasonic sensor (HC-SR04) to help the students understand how avoid obstacle’s using sensors. However, we are not able to get the Ultrasonic sensor object to return any useful values. The getRangeInches() method always returns 0.0.
Here is the setup.
On the Romi, we’ve installed the 5V jumper and setup EXT0/1 as DIO’s mapping them to DIO 8/9
Our code uses the standard Ultrasonic class as outlined in the WPILib Docs, we even ensure the SetAutomaticMode(true) method is called in robotInit…
public class Robot extends TimedRobot {
// Creates a ping-response Ultrasonic object on DIO 8 and 9.
private Ultrasonic rangeFinder = new Ultrasonic(8, 9);
private final RomiDrivetrain m_drivetrain = new RomiDrivetrain();
@Override
public void robotInit() {
// Start the ultrasonic in automatic mode
rangeFinder.setAutomaticMode(true);
}
/** This function is called periodically during autonomous. */
@Override
public void autonomousPeriodic() {
System.out.println("Range: " + rangeFinder.getRangeInches());
// if (rangeFinder.getRangeInches() > 12) {
// m_drivetrain.arcadeDrive(.5, 0);
// } else {
// m_drivetrain.arcadeDrive(0, 0);
// }
}
}
Any thoughts?
Thanks!
Karl Fleischmann
Lead Mentor
Team 7491 - Cyber Soldiers
We could not figure out how to get DIO ultrasonics to work with the Romi. We went with analog instead, and they work well. We could get the DIO channels working, but the ultrasonic pulse/trigger communication was broken. We assumed it was in the timing. We tried to roll our own DIO-based ultrasonic code, but then got overwhelmed and moved to other projects. This happened with both the HC-S04 and the VEX Ultrasonic.
I’ve confirmed that the sensor is working by setting it up on an Arduino. Was able to get it to measure distances quite well. I do have small oscilloscope. I’ll give that a try and see if I can see any signals on the lines when connected to the Romi.
I’m leaning towards using the analog ones too. We have a few of the maxbotic. It’s just got me puzzled that the SR04 works everywhere else but not here. Good thought about the timings, but I also wonder if it’s an electrical thing. Perhaps it needs a resistor (pull up/down maybe like this) to ensure the echo signal can be ‘heard’. I know the RIO has a built in one that sometimes needs adjustment, not sure if the Romi does. My electronics knowledge is quite limited. Maybe experimenting with an oscilloscope as @tkchan suggests will help to see what’s going on. Thanks for the input!
If you have a scope and Arduino handy, I would suggested to just setup the Arduino to send out a regular square wave (trigger) and look at the echo (response). That’ll eliminate the HW being any issues. (you can then move your ‘target’ further away and closer to make sure that the ‘time’ response does correspond to somewhat of a distant (remember these sensors are essentially point source so any echo from ‘sides’ can be an issue/interference so at least make sure during testing that you have nothing on the side that are causing interference).
once you can rule out HW being an issue, then you can look at the trigger and response on the scope after hooking it back up to the ROMI. [my gut tells me that most likely you’ll need to attach a simple RC network on the DO/trigger line - and possibly on the return as well - again, the scope should be able to tell you how clean those are and how they might impact the ‘auto’ mode code in WPILib].
I suspect you are just running into the limitations of network latency in the Romi architecture.
Your robot code is running on your PC, communicating over wifi to talk to the Raspberry Pi, which in turn is talking over I2C to the Romi, which is running your GPIO pins. Ordinarily all of these code layers would coexist on the Roborio.
Those ultrasonic sensors work by measuring the precise amount of time it takes between when you raise the “ping” signal and when you get back an affirmative echo signal. So there are two hops: one over wifi, and another over I2C between your timing code and the actual pins being controiled/timed. I do not believe you can get the timing fidelity needed to use the ultrasonic sensor this way.
One possible solution is for the timing code to reside completely on the Romi controller (which is just a simple Arduino) and for a higher-level protocol to report the pulse timing back to the robot code over the network.
I would be interested to hear from the WPILib developers if they have a plan on the roadmap for handling more kinds of sensors on the Romi, or how they envision teams coding up these kinds of custom interfaces.
Maybe experimenting with an oscilloscope as