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
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....
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.
There are a few things which cause this delay, as per the comment in
Guides\Simulation modes.txtwe usually expect everything to be ready for the lights change about 10 seconds after theSimulationFull.pyscript 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:
Settings.simulationLagFramesto simulate the delay from the real camera.Settings.lightsBurnFramesbefore 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.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.lightsBurnFramesvalue will throw away three times as long as it should do.If things are running slowly there are four likely culprits:
SimulationFull.pyscript is not keeping up.For example running on a Pi Zero or having other things running in the background using CPU time.
This is most likely with older machines or ones with particularly weak graphics cards.
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
Settings.pyand the simulator.In particular if
imageWidthandimageHeightdo not match the simulation then each frame is resized inSimulationFull.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 :)
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
The
simulationLagFramessetting 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 :)
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
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 :)
Nice one, thanks Arron!
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
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.
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 :)
Add new comment