Using one raspberry pi for 7 ultrasonic sensors, 2 camera's

[kks]

Hello,

I am pretty new to raspberry pi but not to programming. I want to know if one raspberry pi can handle processing 7 ultrasonic sensors and displaying readings on a custom lcd at the same time record using one raspberry pi camera module and one usb camera (video only) and save and upload file using given wifi or gsm module. And also act as a audio player or hands free within a car. I have searched but I couldnt get any answers on this. (from what I have read one camera module and one usb camera takes alot of cpu power on its own).

I have already got a raspberry pi 3 model b and have the ultrasonic sensors working and giving me the reading. Now before I order the camera modules and the lcd I want to know if the raspberry can process that many functions.

From the programming side, I am thinking of making a loop script which will create separate threads for each function (recording, showing distance and beeping if close, respond to lcd touch input). Also what are the ways to boot into a custom GUI instead of raspian desktop? Like a gui where the top 3/4th part is the readings on the ultrasonic sensors on their actual location and the bottom with tiled apps.

If I cant do that, I want to know if it is possible to use the same lcd to take input and show output but run multiple raspberry pi's on the background sharing the data? But how fast can the data be shared like reading of the sensors and reverse camera while reversing.

[mthomason]

I can't tell you if it'll work. My thinking is, you'll have to try. You may find the camera data streams interfere with the timing on the ultrasonic sensors, you have to be pretty accurate at timing the "pings" on those.

I can tell you what you could do if you run into a problem - offload the sensors onto a microprocessor such as an Arduino (cheap Arduino Nano clones can be found for under $5), and have that report the values it gets to the Pi over i2c or a serial connection.

[kks]

I can't tell you if it'll work. My thinking is, you'll have to try. You may find the camera data streams interfere with the timing on the ultrasonic sensors, you have to be pretty accurate at timing the "pings" on those.

I can tell you what you could do if you run into a problem - offload the sensors onto a microprocessor such as an Arduino (cheap Arduino Nano clones can be found for under $5), and have that report the values it gets to the Pi over i2c or a serial connection.

Hmm, will there be any delays on the reading?

[joan]

You haven't really given enough detail.

Where are these sonar rangers? Are they to be read simultaneously? Do their ranges overlap? How often will they be read? What sort of rangers are they?

How much video data will be transmitted per second? Along what interface?

[kks]

You haven't really given enough detail.

Where are these sonar rangers? Are they to be read simultaneously? Do their ranges overlap? How often will they be read? What sort of rangers are they?

How much video data will be transmitted per second? Along what interface?

Right now I am using HC-SR04, but I am waiting for my JSN-SR04T to arrive which is similar to HC-SR04 but waterproof. They are to be read simultaneously and alert me if I am close to something. Like a parking sensor works. Their ranges wont overlap as all of them will be in different positions on the car.

I am not sure how much data will be transmitted per second. I will be using the Raspberry Pi Cam module and process it to record only if there is motion. (same goes the back cam, for that I will be using a normal webcam or maybe this: https://www.amazon.com/Esky-Viewing-Wat ... s=EC180-19 if I can figure out a way to make it work)

[mthomason]

I can tell you what you could do if you run into a problem - offload the sensors onto a microprocessor such as an Arduino (cheap Arduino Nano clones can be found for under $5), and have that report the values it gets to the Pi over i2c or a serial connection.

Hmm, will there be any delays on the reading?

Yes, but it should be in the region of microseconds.

If you run into problems either way, you're going to be balancing timing issues with the Pi giving you inaccurate readings vs timing issues on the polling delivering the readings a little late. Both *ought* to be extremely minor, but personally I'd go with a microprocessor solution because it's more likely to avoid any contention issues between other Linux-ey processes running on the Pi at the time. I'd always be afraid that Linux decided that second would be the best time to do some background stuff with the filesystem or something.

That said, given enough time and resources I'd prefer to try out both and see which works best. Then again, I'd also prefer to wire the microprocessors directly to any warning buzzer/light and just inform the Pi in the background. Overall, though, what you're doing sounds more to me like a microprocessor job (limited processing, time critical, always on) than a computer one (complex decision making, may occasionally need rebooting or restarting, other tasks could interfere with timing) - so microprocessor(s) running the proximity warning system, and a Pi responsible for things like GPS navigation.

I know... I've contradicted myself here, but I'm just thinking out loud really and trying to make sure you get all the options and their pros/cons

[kks]

I can tell you what you could do if you run into a problem - offload the sensors onto a microprocessor such as an Arduino (cheap Arduino Nano clones can be found for under $5), and have that report the values it gets to the Pi over i2c or a serial connection.

Hmm, will there be any delays on the reading?

Yes, but it should be in the region of microseconds.

If you run into problems either way, you're going to be balancing timing issues with the Pi giving you inaccurate readings vs timing issues on the polling delivering the readings a little late. Both *ought* to be extremely minor, but personally I'd go with a microprocessor solution because it's more likely to avoid any contention issues between other Linux-ey processes running on the Pi at the time. I'd always be afraid that Linux decided that second would be the best time to do some background stuff with the filesystem or something.

That said, given enough time and resources I'd prefer to try out both and see which works best. Then again, I'd also prefer to wire the microprocessors directly to any warning buzzer/light and just inform the Pi in the background. Overall, though, what you're doing sounds more to me like a microprocessor job (limited processing, time critical, always on) than a computer one (complex decision making, may occasionally need rebooting or restarting, other tasks could interfere with timing) - so microprocessor(s) running the proximity warning system, and a Pi responsible for things like GPS navigation.

I know... I've contradicted myself here, but I'm just thinking out loud really and trying to make sure you get all the options and their pros/cons

Thank you Well i guess I will use arduino and conenct it to buzzer and LCD directly and make it switch on/off with the car. And I will make the raspberry handle the camera's and everything else and also get the reading from the arduino when the car is in reverse gear.

[PiGraham]

It might be possible. You don't need the sensors to run simultaneously. You won't notice if you operate them sequentially, maybe every 100ms.

Note you shouldn't operate multiple HC-SR04 simultaneously anyway because reflections from one may confuse the reading from another. You need to let the chirp of each sensor travel out and return before making the next one chirp.

Two cameras is no problem at all. One PiCam and one USB webcam will work fine.

[kks]

It might be possible. You don't need the sensors to run simultaneously. You won't notice if you operate them sequentially, maybe every 100ms.

Note you shouldn't operate multiple HC-SR04 simultaneously anyway because reflections from one may confuse the reading from another. You need to let the chirp of each sensor travel out and return before making the next one chirp.

Two cameras is no problem at all. One PiCam and one USB webcam will work fine.

This is how I am doing it now.

Code: Select all

def getdist( ECHO ):
	GPIO.output(TRIG, False)
	print "Waiting For Sensor To Settle"
	time.sleep(0.01)

	GPIO.output(TRIG, True)
	time.sleep(0.00001)
	GPIO.output(TRIG, False)

	pulse_start = 0
	pulse_end = 0
	pulse_duration = 0


	while GPIO.input(ECHO)==0:
	  pulse_start = time.time()

	while GPIO.input(ECHO)==1:
	  pulse_end = time.time()

	pulse_duration = pulse_end - pulse_start

	distance = pulse_duration * 17150

	distance = round(distance, 2)
	return distance

I run a loop with this function being called for each sensor and then print the values. So I can run this with a raspberry pi cam and usb web cam with a touchscreen lcd display to display the values?

Also may I know if it is possible to use 3 pi's (1 for each cam and 1 with sensors and lcd conected) and transfer all the video data live without issues?

[PiGraham]

Run the range finding in a separate thread. Put a longer sleep in that loop, say sleep(0.1) or sleep(0.01) so that it doesn't hog the CPU, but gives you rapid distance updates.

Alternatively use GPIO change callbacks to handle the sensor pulse timing. Starts each sensor in turn from the main thread in between doing other things and use the callbacks to time the pulse. on Rising edge save the start time and on falling edge read the end time and calculate the distance.

Do the video and display code in the main thread.

Search "python multithreading" for examples and tutorials.

Please note that I haven't used HC-SR04 sensors or timed pulses with python while recording video. I can't guarantee it works, but I think there is good chance it will work and is worth trying. I have displayed simultaneous live video from Pi Cam and USB cam and that works fine. I used PiGame:Camera for that

[timrowledge]

Joan's PiGpio library (already included in the latest Raspbian releases) can handle the SR04 type sensors easily. If you look at her example page http://abyz.co.uk/rpi/pigpio/examples.html you'll find several approaches to 'sonar ranger' to look at.

[kks]

Run the range finding in a separate thread. Put a longer sleep in that loop, say sleep(0.1) or sleep(0.01) so that it doesn't hog the CPU, but gives you rapid distance updates.

Alternatively use GPIO change callbacks to handle the sensor pulse timing. Starts each sensor in turn from the main thread in between doing other things and use the callbacks to time the pulse. on Rising edge save the start time and on falling edge read the end time and calculate the distance.

Do the video and display code in the main thread.

Search "python multithreading" for examples and tutorials.

Please note that I haven't used HC-SR04 sensors or timed pulses with python while recording video. I can't guarantee it works, but I think there is good chance it will work and is worth trying. I have displayed simultaneous live video from Pi Cam and USB cam and that works fine. I used PiGame:Camera for that

Thank you. I will try using GPIO callbacks.. seems like a better way than using while statements