run_camera.py debug about foos HOT 15 CLOSED

So, to run the camera you have to enable the corresponding plugins in config.py:
So you should enable "camera", and "replay" and disable "replay_debug".
(Basically adding the two to the plugins list in config.py and removing replay_debug)
The main program foos.py should take care of running everything and creating the necessary directories for the replay - Did you do that?
If you want to run run_camera.sh by hand you have to give it a base_path (try for example run_camera.sh /home/pi/replay) where to write capture files and replays - take a look at the script to see what it's doing.
It's not really thought to be run by hand and it's not doing any error checking :S

from foos.

thanks for the info - I hadn't enabled the right plugins so that was the issue - I've done that now though and I'm getting the top left visual from the picam in the GUI 👍

Was trying to use sh instant_replay.sh to ensure the replay was working - but the the replay seems to skip through with nothing. - I guess it's because there's nothing recorded.

Any suggestion of how I could test the instant replay before I finally crack open the foos table?

Thanks a lot in advance,

from foos.

Ok - do verify that you have disabled the "replay_debug" plugin and the "replay" plugin is enabled.
Check if there are fragments in your the directory where foos is running.
So probably in /home/pi/foos/replay/fragments - these are the video chunks from the replay.
As soon as a goal event ocurrs (or the instant_replay request) the files foos/replay/replay_short.h264 and foos/replay/replay_long.h264.
If these are fine, check that you can play them on the pi with /opt/vc/src/hello_pi/hello_video/hello_video.bin (this is the binary we use to replay).
Do also check the console output after you quit foos - it should complain about if there's anything missing!

from foos.

cool - I can verify "replay" enabled and "replay_debug" is removed.

I'm in /home/pi/foos/video/fragments rather that /home/pi/foos/replay/fragments - which I guess should be fine - but I don't have any fragments generated in here - I thought these would be generated automatically based on the motion detected but I though I might be able to fake this with the movement, then triggering a goal by ssh into the pi. - but maybe I'm wrong on that and I should just throw in some fragment there for testing and assume the fragments will be created correctly once I finish hooking up the arduino?

from foos.

No no, the camera should be generating fragments continuously - and it's running, as you've said that you can see the little window in the corner.
Sorry I forgot that the replay_path is actually configured in config.py - by default it's /home/pi/replay.
The folder you mentioned must have been created when you ran the script manually.
Check what is in there, please.
You can also verify where raspivid will write checking the paramters doing:
ps ax | grep raspivid
Motion detection is another thing that works on the utput that raspivid generates.
If the camera is running you should see that fragments are being written in /home/pi/relay/fragments.

from foos.

ah gotcha - makes more sense - I've adjusted the config file to my video location as that had /fragments/ in it anyway - I checked with grep raspivid and all looks good and when running foos.py now my fragments dir is filling but, under my /video/ dir that was created i don't have replay_long.h264 replay_short.h264 - so I guess that's still not working.

I'll try switching it all back over to /replay/ now to see if that resolves things

from foos.

Just to be clear:
The two replay videos are generated whenever a goal/replay event occurs - so in your case when you run the debug/instant_replay.sh or debug/goal_black.sh.
So check that they are generated when you run any of these scripts and then check that the player I mentioned works.
I recommend you to delete all files of your old video directory. foos mounts the dir for replays in RAM so that it doesn't fry the SD card, so to free up some RAM delete those old files.

from foos.

ok so I've tested the player and can confirm my hello_video works.
My replay path is now set as replay_path = '/home/pi/replay'

and my camera and replay plugins are enabled with their counterpart debug plugins disabled.
now when debugging with sh instant_replay.sh I'm getting the wipeaway that pushes score to the top right but the camera in the top left stays minimised and I have the console running behind. Where I can see that a new debugging session is running...but not much else.

Am I missing something obvious on this, I did a complete fresh install on a separate raspi so it should be fairly clean as far as setup goes.

Appreciate the help in further debugging!

from foos.

Hey @danpillay87
Sorry to hear that it's still not working.
Just FYI: The camera will always be visible in the top corner - What should happen is that the video of the replay is being played in the background.

Can you please answer the following questions:

• Do you see any errors/messages on the console where you ran python3 foos.y while toing the replay?
• How long does it take for the counter to go back to their normal size?
• Do you have /home/pi/replay/replay_short.h264 and/or /home/pi/replay/replay_long.h264?
• If yes: Can you play this file with /opt/vc/src/hello_pi/hello_video/hello_video.bin and does this show the video on the screen? Any errors/output on this program?

I think there's nothing obvious wrong - the most important would be to check any error messages to see what's wrong...

from foos.

@swehner appreciate the support so far.

I took a break and I've returned motivated to find the solution! in answer to your questions:

• the replay isn't showing any errors my logging shows the standard for the GUI
  loading plugins ['replay', 'camera', 'score', 'game', 'io_debug', 'menu', 'control', 'league', 'event_debugger']
  loaded all plugins.
  Run GUI
  Getting game mode None None
  compiled
  compiled
  opened new bugging session
  goal_event: {'team': 'black', 'source': 'serial'}
  .... so doesn't seem to be anything there....
• the counters don't appear to return to their normal size - they just reduce, showing the console in the background, so not sure if I should be running this differently in production somehow?
• I do have both those files
• I can indeed play the files with hello_video.bin if I move them out of the dir but it isn't playing if i've already ran foos.py - and after reboot the /replay/ dir appears to be empty again - which I'm not sure if is intenational - as the /fragments/ dir and the replays themselves seem to be only created after running foos.py

Apologies I don't have a useful error message but any ideas welcome!

from foos.

on exit of foos.py - to try and debug the issue further, if I've triggered sh instant_replay.sh and then exit I'm getting the following errors:

traceback (most recent call last):
File "/home/pi/foos/foos/ui/ui.py", line 469 in run while self.DISPLAY.loop_running():
File "user/local/lib/python3.4/dist-packages/pi3d/Display.py", line 283 in loop_running self._loop_end() # finish the previous loop.
File "user/local/lib/python3.4/dist-packages/pi3d/Display.py", line 364, in _loop_end time.sleep(delta) keyboardInterrupt

from foos.

Hey,

So, to answer your questions:

• Output looks good
• Counters not returning to normal size, means that hello_video.bin runs, but doesn't finish.
  Can you check if hello_video.bin is running all the time while the counters are reduced in size?
  ps ax | grep hello_video
• It's normal that replay is emptied after restart - it is mounted in RAM. So the files are not written again and again to the SD card.
• The traceback you see is normal - it's just that the Ctrl+C is not handled specificially and it just exits forcefully - but that's normal.

I dimly remember us having a similar issue as this - video player hanging and never stopping - and I think it was related to the GPU memory size. Can you check and raise the GPU memory split a bit more?
Try 192M or 256M using raspi-config.
After reboot you can verify that it is set correctly using: vcgencmd get_mem gp
Let me know if that changed someting.

from foos.

This was the issue I created back then: #5
I remember that it took us quite some time to figure out it was memory related.

from foos.

ah - ha that seems to have done the trick - a quick up to 256M with raspi-config and we're sorted! excellent shout - for sure wouldn't have isolated memory was the issue alone! thanks @swehner - I'll be taking the table apart first thing tomorrow!

from foos.

Awesome! Have fun!

from foos.