Monster borg start procedure

12 posts / 0 new
Last post
casramsey
Monster borg start procedure

Hi - wondering if anyone else is having the same issue...I've just gone from the yeti code to the monster code and I'm finding that when I use the simulator and go through the start procedure, the code doesn't recognise the light changes for a period of time.

To ensure I hadn't done something daft, I have just downloaded a clean version of the monster code. When I go through the start procedure Off > Green > Red > Green, the code does not recognise any of the light changes. If I wait a period of around 20-30 seconds it will recognise light changes if I redo the start procedure, but nothing until that point. Like I said, I have done this with clean code from the repo and on two different computers with the same outcome. Did I miss a post somewhere that changed the start procedure for the monster code or something (although it's more that the colour change isn't being recognised)?

Thanks kindly
Cas

Thomas
same problem

Here too. I've already investigated a little bit but it's not so obvious what's wrong. It is reproducible so with enough time....

marlebru
marlebru's picture
Monster start concern

I too have noticed that the base Monster code has trouble detecting the initial green (I also migrated from Yeti to Monster on my pi). It does typically pick it up after I toggle from Green to Off and back to Green Once or twice in the simulator, but it does make me nervous for our first test run next week.

Arron Churchill
Arron Churchill's picture
Delay before lights detection

There are a few things which cause this delay, as per the comment in Guides\Simulation modes.txt we usually expect everything to be ready for the lights change about 10 seconds after the SimulationFull.py script starts showing FPS readings.

Having a delay there is quite normal and partially intentional. We give the robots a total of two minutes to power up and get ready for detecting light changes. With the Pi 3 in a MonsterBorg the script has started much earlier than than (worst case 30 seconds) so this delay should have no real effect on the actual running of the robots.

The delay comes from a few parts of the system, some of which are intended:

  • There is an injected lag which delays incoming frames by Settings.simulationLagFrames to simulate the delay from the real camera.
  • Once ready to start the lights detection throws away a total of Settings.lightsBurnFrames before checking for lights. We do this to give the Pi camera a chance to settle down (auto-tuning) before we start relying on the image data.
  • There is some delay before the code gets running properly as some of the filters take time to fill up.
  • The code starts printing FPS readings a little bit before it is actually ready to go.

If the delay is excessive (like your 20-30 seconds) it suggests something is running slowly. You can tell if this is true from the FPS values shown, which should be around 30 for the Monster code. If the values are much lower than this then the frames delayed and thrown away will count for longer than they are meant to. For example if the code is running at 10 FPS then the Settings.lightsBurnFrames value will throw away three times as long as it should do.

If things are running slowly there are four likely culprits:

  1. The machine running the SimulationFull.py script is not keeping up.
    For example running on a Pi Zero or having other things running in the background using CPU time.
  2. The machine running the simulator is unable to generate a stable 30 FPS stream.
    This is most likely with older machines or ones with particularly weak graphics cards.
  3. Poor network connection (particularly WiFi).
    Lag spikes or poor bandwidth can cause the FPS to suffer as individual frames get delayed, this is the most likely culprit if the FPS values are especially erratic before the lights change
  4. Miss-matched settings between Settings.py and the simulator.
    In particular if imageWidth and imageHeight do not match the simulation then each frame is resized in SimulationFull.py, which slows down the code.

On a side note this is part of the point of testing round 0. It should give everyone a chance to iron out any problems like this before testing round 1, even for any problems we have in the standard code :)

awood85
awood85's picture
Lag

On the subject of Settings.simulationLagFrames - has the default value been setup to match the real Mosterborg or has it been scaled based on the lag values from the Yetiborg? If its a real value how is this done?

Thanks

Adam

Arron Churchill
Arron Churchill's picture
simulationLagFrames setting

The simulationLagFrames setting has been adjusted for the MonsterBorg, but it is really based on time delay.

During some of the early testing we wrote some code to detect light changes and used some LEDs controlled from a GPIO pin on the Raspberry Pi to effectively time the delay between changing the LEDs and seeing the result back from the Pi camera using the Video4Linux interface.

At 60 frames per second we were seeing a reasonably consistent 0.15 seconds (9 frames) delay compared to ideal. This also seems to hold at about 5 frames at 30 frames per second.

When we wrote the YetiBorg code we took the assumption of a 1 frame delay for 5 frames per second. If anything this means the YetiBorg delay was based on scaling our first version RC car code down from 30 frames per second :)

awood85
awood85's picture
Does this mean there is

Does this mean there is minimal delay (unrealistic) in the simulation without having a sensible value in? e.g. the camera frame takes longer than the URL frame? I suppose it depends on the connection quality and processing performance (both ends).

Thanks

Arron Churchill
Arron Churchill's picture
There is :)

That is right, on a good connection the network delay seems to be in the order of 5 to 20 ms, which is less than a single frame at 30 frames per second. Slow processing on the simulator side does have an effect, but not as much as the quality of network connection.

On a side note the delay is incredibly small if both parts of the code are running on the same machine. It also removes any lag spikes from network traffic which makes things very stable :)

casramsey
Nice one, thanks Arron!

Nice one, thanks Arron!

povilas
can not launch SimulationFull.py

Hello,
can you help me please
how can I run SimulationFull.py"
when I try to run
python SimulationFull.py
I getting error message
I have read "simulation modes.txt" , but it is still not clear how to run code

Thank you

Comment Images: 
dinotoo
Hi,

Hi,

I follow this guide (option 2 : « manually run through the steps ») and launched sim on a rpi3 without any problem : https://www.formulapi.com/race-code/sd-card-monster-summer-2017

Did you launch all commands ?
./install.sh
sudo apt-get -y install python-picamera
sudo apt-get -y install libcv-dev libopencv-dev python-opencv

If it doesn t works, don t waste your time, Flash the SD with exactly same Linux debian and follow the guide like I did.

However, rpi part of code works on a Windows 7 with exact version of python/opencv/... you can find on the sim guide. So you don t need a rpi for start working.

povilas
Hi again,

I managed to launch simulation
though I got an error when I tried to run simulation
python SimulationFull.py

File "SimulationFull.py", line 34, in
os.chdir(scriptDir)
OSError: [Errno 2] No such file or directory: ''

after some research I have found my mistake
instead of python SimulationFull.py
python ./SimulationFull.py
I also in SimulationFull.py changed simulation server address to my windows machine ip

Thank you for your help
and I hope this post will be useful for those who will struggle to launch simulation :)

Comment Images: 

Add new comment

Filtered HTML

  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd> <pre>
  • Syntax highlight code surrounded by the <pre class="brush: lang">...</pre> tags, where lang is one of the following language brushes: bash, cpp, perl, python.
  • Lines and paragraphs break automatically.

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Comment Images
Files must be less than 10 MB.
Allowed file types: png gif jpg jpeg.
Comment Attachments
Files must be less than 10 MB.
Allowed file types: txt pdf nfo doc docx rtf jpg png gif bmp zip tar gz csv xls.
CAPTCHA
This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.