When running opencv-viewer.py, 9 out of 10 times we get stuck at "Socket connected.", i.e., we can connect to the NINA, however no packets can be received. The NINA blinks at that point fast, indicating that it believes that a connection was established.
We did have the same problem with the version from the master branch. I am wondering if anybody else has seen this and if there is some trick to connect more reliably.
That are indeed not very good stats... When we had this there was hardly any problem connecting to the viewer, so let's see what your conditions are:
- Was this with the program on RAM (make run) or flashed (make flash)?
- Did you in between those try to restart the aideck by powercycling the crazyflie? And perhaps also connecting and reconnecting the battery?
- The software access point, is there any security on that that might prevent the connection? We had to make a new wifi point especially for working with the nina.
- We flashed using the Olimex.
- Yes, we tried to restart the Crazyflie, both with the button and also by re-plugging the battery.
- By software access point I mean that the NINA is creating an access point (similar to a router), and we connect our Laptop to that (NINA) access point. For security reasons, we are not allowed to have our own router in the lab. This is essentially the same mode the AI decks ship with from the factory. (And we do have the same problem with the factory firmware.)
The reason why I asked if you tried on RAM flash (so that you see the debug logging through the olimex) or flash on RAM, is that we had some people before that mentioned that the wifi example with 'make run' did work but 'make flash' didn't, which perhaps indicates some kind of timing issue that prevents the Camera from starting or is causing problems with the SPI communication. If you do 'make run' as well, you can check if the camera is starting at all or not.
I'm a bit worried though that you mentioned that you have had the same with the factory setting... I assume you were using 'masters' viewer.py then and not the one from the special branch right? Have you also build the crazyflie firmware with the forced AIdeck driver?''
Currently I'm on my windows side of things so I won't be able to try it out yet, but I'll see if I can find some time this afternoon to switch OS and see if I am able to replicate it some how.
But at least you know know that there is something not quite right, and also the current state of the firmwares is a bit in Limbo right now... so we hope to resolve most of these problems in the coming weeks anyway with some well thought out code Do you by any chance have another AIdeck to just double check if it is perhaps an error in your AIdeck?
Thanks for your generous offer! I debugged this further today (using the logging output over UART). The issue is that the GAP8 seems to stall everytime in
Code: Select all
I am using https://github.com/bitcraze/AIdeck_exam ... 8-firmware with the provided docker container. I don't fully understand the statement in the README:
* I didn't see any error message when flashing, and flashing generally seems to work (e.g., I am able to change the SSID/Password successfully).Note: Due to a bug in the Makefiles in the SDK you will need to use our toolbelt to build/flash the application, or fix the Makefiles as described in this issue.
* When you write "toolbelt", I assume you mean the provided docker container, i.e., when using the docker container, no further actions are needed?
Finally, this looks like some sort of race condition perhaps. Are you aware of any other problems where running works fine, but flashing doesn't? I can easily reproduce this using two different 1.1 AI decks, although the stalling within open_pi_camera_himax happens at slightly different places.