Problems in testing round 2
During the stream for Test 2 we had a long list of problems, most of which we have not seen before:
- Stream glitches / dropouts
- Timer sensors not working properly
- Two robots which started and stopped still on the first straight
- Two robots which did not start with the lights
- One robot which jumped the lights :)
- One robot which did not even boot up correctly :(
As you can imagine this was rather frustrating for us and all the competitors, so we set out to try and find the cause of all these problems.
Stream glitches / dropouts
If you have not seen the stream yet you may wish to watch it first to avoid any spoilers:
What is probably not obvious from the recording itself is that we had several occasions where the stream got stuck and was struggling to keep up :(
We use OBS Studio to stream all of the Formula Pi rounds and it has a streaming health indicator in the bottom right. What we saw is this was briefly going to red and showing 0 Kb/s stream rate, then recovering back to a reasonable number. Our assumption is that something was preventing the stream from being steady.
We did try and investigate this during the stream, but to no avail. First we tried turning any non-essential computers, phones, et cetera off. At first this seemed to have helped, but it soon started failing again. We then tried restarting the feed from the cameras to the streaming machine, this made no difference.
In the end we decided to solider on and do the best we could. After the stream we turned all of the machines off and restarted our internet router. The next morning we were streaming again for the RaceYourCode entrants, this seemed to now all be fine again...
We believe this was either a problem with our router or the internet connection during the stream, however we have no real way to confirm this :(
Timer sensors not working properly
As some of you noticed already two of our sensors for split times were not working during the test session. The culprit here was the laser sensors we have on the track:
It turns out that when we went to look at these the next morning both sensors did work, but only if the object passing was moving slowly...
We got our oscilloscope out and the problem became obvious, our tuning resistors were wrong! We use some resistors to change the voltage level from the photodiode sensor into a simple logic on / off signal. When the beam was broken this "off" voltage was a bit too high, causing the rest of the circuit to react very slowly to the change. This meant a brief "off" was not enough to trip the signal, so no time was recorded.
Our best guess is that the values we used work in summer, but are a bit too close for winter temperatures. Timothy has now changed these resistors for better values and they are working even better than before :)
Two robots which started and stopped still on the first straight
There were two robots that did the same strange start then stop routine which ran back-to-back. First there was Chitty Chitty Pi Pi (98):
Then Enigma (10) did the same thing:
At first we though this must be something we had done, why else would two teams do the same strange thing one after the other? It turns out we were indirectly the cause.
Basically our DetailedLap.py
example contains the following line:
while time.time < endTime:
This makes no sense as it compares a function and a number, which always returns False
, in turn this causes the loop not to run. The correct version is:
while time.time() > endTime:
Which compares the current time to a predetermined finish time.
In both cases the teams had copied this bad line into their Race.py
code, which then decided the race had finished as soon as it had started :(
Two robots which did not start with the lights
This was much more unfortunate, both X STATIC (100) and SolarCats (96) had code which did not see the lights at all. On investigation in turned out both entries had basically the same code bug which caused the script to fail before the lights had even begun.
This is an important one as it can be tricky to spot and most programming languages do not care about it. They both had some incorrect indentation in the code.
To explain here is a very simple bit of Python:
if someValue > 10: runFunctionA() runFunctionB()
In this case Python uses the fact that lines 2 and 3 are shifted to the right by spaces to mean they only happen depending if line 1 is actually true. If however we make a mistake like this:
if someValue > 10: runFunctionA() runFunctionB()
Python cannot tell what line 3 should belong to, it just knows it is not the same as line 2. This causes it to return an error.
This does not seem too bad until you find out this space can be one of two different things: a tab character or a space character. With the correct number of spaces the tab character can look identical, but Python treats it as different. This causes an error and prevents the script from running :(
One robot which jumped the lights :)
While it was rather amusing to see Pico HulkenBorg (87) start driving without warning, it would have disqualified them in a proper race round.
It turns out they have a piece of code which detects if it has been waiting for the lights for too long, in which case it probably missed them. This would allow the robot to run properly even if the light detection failed to work. The only problem is that they had not anticipated us having a bit of a chat during the stream and delaying the lights :)
One robot which did not even boot up correctly :(
Our last problem of the day was FarStar's (103) entry failing to load on the MonsterBorg at all. We could tell this because the LED on the MonsterBorg never changed to their assigned colour for racing.
It turns out this was just a mix-up between the older Grand Pi code for the YetiBorgs and the newer Monster Series code for the MonsterBorgs. Put simply the Grand Pi code will not load on a MonsterBorg because it cannot communicate with a ZeroBorg controller.
In summary
So overall we had a good mixture of problems during the stream. Some were our fault, some were competitor issues, and the big one we are not sure who is really to blame...
Hopefully the streaming trouble was just a bad day, we have not seen that type of issue before. All I can say for sure is that we will be watching out for this like a hawk from now on.
Add new comment