I'm trying to run a Python script on my Raspberry Pi 3B. It involves the OpenCV and the Tensorflow libraries, for object recognition. The camera I'm using is a Nilox MiniF action cam, set to the lowest quality (720p@30FPS). As I run the script and after a few seconds RasPi crashes and reboots. I thought I was demanding a bit too much from the hardware, so I tried to get only 1 on 10 (then 100, 1000 and 100000) frame. Nothing changes: RasPi keeps crashing, and it doesn't seem to leave any message in the messages or kern.log files. Could it be that my cam is too much powerful for my hardware? Is there a particular reason to use PiCamera instead of another cam?

Since I'm new to the Raspberry Pi world, consider the option that's I've made a very basic mistake.

EDIT: As requested, that's the script I'm trying to run:

import tensorflow as tf
import os
import cv2
import numpy as np
import sys

# First, pass the path of the image
#images = []
cap = cv2.VideoCapture(1)
## Let us restore the saved model
sess = tf.Session()
# Step-1: Recreate the network graph. At this step only graph is created.
saver = tf.train.import_meta_graph('results/steering_model.meta')
# Step-2: Now let's load the weights saved using the restore method.
saver.restore(sess, tf.train.latest_checkpoint('results/'))
# Accessing the default graph which we have restored
graph = tf.get_default_graph()

classes = ['forward', 'left', 'right', 'stop']

    # Reading the image using OpenCV
    _, frame = cap.read()
    ## Testing a single image
    #frame = cv2.imread("dataSet/images/stop/192.jpg")
    # Resizing the image to our desired size and preprocessing will be done exactly as done during training
    image = cv2.resize(frame, (image_size_x, image_size_y), 0, 0, cv2.INTER_LINEAR)
    grayTrue = cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY)
    image = cv2.Laplacian(image, cv2.CV_64F, ksize=31)
    # The input to the network is of shape [None image_size image_size num_channels]. Hence we reshape.
    x_batch = image.reshape(1, image_size_y, image_size_x, num_channels)

    # Now, let's get hold of the op that we can be processed to get the output.
    # In the original network y_pred is the tensor that is the prediction of the network
    y_pred = graph.get_tensor_by_name("y_pred:0")

    ## Let's feed the images to the input placeholders
    x= graph.get_tensor_by_name("x:0")
    y_true = graph.get_tensor_by_name("y_true:0")
    y_test_images = np.zeros((1, len(os.listdir('dataSet/imgs/'))))

    ### Creating the feed_dict that is required to be fed to calculate y_pred
    feed_dict_testing = {x: x_batch, y_true: y_test_images}
    result=sess.run(y_pred, feed_dict=feed_dict_testing)
    resultArray = np.argmax(result)

    cv2.putText(grayTrue,"Prediction: " + str(classes[int(resultArray)]), (30, 350), cv2.FONT_HERSHEY_SIMPLEX, 0.5, 230)

    # Display the resulting frame
    cv2.imshow('frame', grayTrue)
    if cv2.waitKey(1) & 0xFF == ord('q'):

# When everything done, release the capture
  • Perhaps adding the script could reveal something.
    – MatsK
    Jun 2, 2018 at 18:08
  • Does it have a power source that can handle the load? How many amps does it have on the output? It should be something like 2.5A to know that it will work reliably. Also, can you check /var/log/syslog files?
    – eftshift0
    Jun 2, 2018 at 18:51
  • @eftshift0 I was using a 5V 1A power supply, since I read on the RasPi manual that every supply over 700mA works. Also, haven't thought to give it more power because the cpu and ram usage didn't seemed to be that high while running the script, so I thought that mine was a "light" script. Anyway, I also checked syslog but didn't find anything useful. Jun 3, 2018 at 9:08
  • @MatsK I edited and added the script. Jun 3, 2018 at 9:08
  • .7A was ok for the previous models (pi2 and stuff). Pi 3B goes up with some 2.5 if I'm not mistaken. that might be the source of the problem.
    – eftshift0
    Jun 3, 2018 at 17:02

1 Answer 1


This is very likely a power issue. When you run the script, the camera requires additional power, thus there is an increase in current draw over the USB cable. When there is an increase in current on the USB port (or anywhere else on the RPi), the Raspberry pi increases the draw from the microUSB cable which is powering it. If the microUSB cable and/or charger can not handle the increased current draw, then the voltage will drop below the threshold and the Raspberry pi will shut itself off.

If it's a power issue, you will see a number of "undervoltage detected" warnings within the following file: /var/log/syslog

To fix this issue, make sure that you are using a USB cable and charger that is rated for between 2.5 and 3 Amps.

Not all microUSB cables are made the same.

  • Yeah, it was a power issue, I got a 2.5A cable and power supply and now everything works fine, Thank you. Aug 18, 2018 at 9:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.