Hi,
I have a problem when I ran the following code.
I tried to print the angle after p.transmitAngle(x);
The code cannot print x continuously. It seems that the sonar stopped scanning. After a pause of a few second, it printed a serial of x again and then paused.
from brping import Ping360
if __name__ == "__main__":
import argparse
parser = argparse.ArgumentParser(description="Ping python library example.")
parser.add_argument('--device', action="store", required=False, type=str, help="Ping device port. E.g: /dev/ttyUSB0")
parser.add_argument('--baudrate', action="store", type=int, default=115200, help="Ping device baudrate. E.g: 115200")
parser.add_argument('--udp', action="store", required=False, type=str, help="Ping UDP server. E.g: 192.168.2.2:9092")
args = parser.parse_args()
def disk_exists(path):
try:
return stat.S_ISCHR(os.stat(path).st_mode)
except:
return False
if args.device is None and args.udp is None:
parser.print_help()
exit(1)
p = Ping360()
if args.device is not None:
p.connect_serial(args.device, args.baudrate)
elif args.udp is not None:
(host, port) = args.udp.split(':')
p.connect_udp(host, int(port))
print("Initialized: %s" % p.initialize())
for x in range(400):
device_data = p.transmitAngle(x)
print(x)
This code worked before without any issues. Thanks.
Beyond the missing imports/setup the code looks fine to me. Could you provide some more information about how you’re running this? I’m curious as to:
which versions of Python and the bluerobotics-ping library are you using?
whether you’re using serial or udp
if serial, which baudrate?
your hardware setup (e.g. Ping360 connected directly to controlling computer/RPi, or Ping360 connected to Companion computer and controlled from topside computer)
if it’s going via Companion, which Companion version are you using?
whether you experience the same pauses when using Ping Viewer
The sonar is connect to a BeagleBone Black through udp.
Before I connected the sonar to the BeagleBone black through usb, there was no problem. But this time I cannot use usb because of one underwater cable I use.
When I connect the ping360 to a laptop through udp, there was no problem.
There is one more problem: I cannot talk to the ping360 through pingviewer if I use an usb to ethernet adaptor, I need to connect the ping360 to the ethernet port in my laptop directly. This is a trouble as the laptops in my lap has no ethernet port.
Could you update your bluerobotics-ping to the latest (0.1.3)?
How is that connected? Have you changed the Ping360 into the ethernet configuration, or are there other connections in between that you haven’t mentioned?
Are you saying you’ve got the Ping360 in ethernet configuration, and it’s working when directly connected to your laptop but not when connected via an ethernet to USB converter? If so, that may be a network settings issue, or a faulty ethernet to USB converter.
I have updated to 0.1.3. There was no stopping for like 30 seconds when I ran my code for the first time. Then when I restarted the sonar, it stopped scanning frequently like before.
I have changed to ethernet configuration. The sonar is connected directly to the ethernet port of the BeagleBone.
There was no problem when connected to the laptop with Pingviewer, but had problem when used bluerobotics-ping with Beaglebone Black. I do not use converter.
Instead of using transmitAngle, I tried to use command control_transducer()+wait_message(). When I only used control_transducer, there was no stop, but when I included wait_message, it stopped. So what I can do now is to set the timeout parameter in wait_message to be a small value instead of using the default value 4. But this means I may miss some data right? But I don’t want the sonar stop scanning.
In the function control_transducer(self, mode, gain_setting, angle, transmit_duration, sample_period, transmit_frequency, number_of_samples, transmit, reserved), I cannot find the explanation of the last two parameters : transmit and reserved. Could you tell me what they mean?
We’ve just fixed a ping-python bug that was causing an issue somewhere else, but may also be related to this. Please try updating to 0.1.4 in case that helps
which is why it’s set to 4 (seconds) in the code. It should be possible to dynamically set a lower value if you know you don’t need the full time (which I’m planning to do in a library update, but that may not occur until some time next year).
If you’re interested, the main steps I’m aware of that are likely factored into that “worst case” time are:
up to 399 gradians of (clockwise) motor rotation while it gets to the hall effect sensor to calibrate the zero position, along with some time to detect/initialise (unsure how long this part takes)
up to 200 gradians of rotation to get to the requested ping position (unsure how long this takes, but it could likely be timed quite easily - the time allocated could be reduced if you know where the requested position is relative to the current position)
1200ms for the transmitting + receiving of a 1200 sample ping with a 1000us sample period (could be reduced if you’re using fewer samples and/or a lower sample period)
some time to send the response message (this may depend on communication mode + configuration (e.g. serial baudrate), as well as how many samples are included)
I’d note that if you’re having connection issues it’s likely best to fix those before focusing on minimising timeouts, but that said, having a failsafe that doesn’t wait around longer than absolutely necessary is still a good idea
The protocol docs I linked to above are the best source of information for things like this. In this case reserved is a reserved parameter, so your best bet is following how it’s used elsewhere in the existing implementations (e.g. in the transmitAngle function it’s just set to 0).
