There are a few ways of developing your code on Raspberry Pis for PiWars:
- write your code on Raspberry Pi using monitor and keyboard attached to the RPi
- write your code on Raspberry Pi using ssh
- write your code on Raspberry Pi using X11 tunnelled back to your computer/laptop's X11 Terminal (client program)
- write Python on your laptop/computer, copy it to Raspberry Pi (scp/samba/...), ssh back to RPi to run it
- use sophisticated IDEs like Pro version of PyCharm that know how to execute Python code remotely piping shell output back to IDE's console
- use PyROS
I've enumerated options from simplest to most complex and from least convenient (it is quite hard chasing your rover with monitor and keyboard in your hands while attached to it) to most convenient. Having IDE doing heavy lifting for you (Pro version of PyCharm) is very useful but it costs money (£70 a year for individuals). Using PyROS is almost as easy as IDE - at least can be made easy.
$ pyros myrover upload -s -r -f wheels wheels-controller.py
This would be an example how to upload new version of 'service' wheels (python file wheels-controller.py) and keep the 'connection' on (-f option) - pumping 'logs' (stdout) back. If at any point you stop it you can continue monitoring stdout from a service by:
$ pyros myrover log wheels
But, all those predicate you use
print statements in Python to log what is going on with you code. In case (as it is ours) we have a few loops running at significant speeds (over 200Hz) gathering data (from AS5600 for wheel orientation, accelerometer, gyroscope and compass from IMU and such). Just imagine the amount of text printed out all the time to stdout. Also, as PyROS utilises MQTT for communication between processes (and shell commands as above) it would make output really big and 'clog' network throughput. Additional problem is that not all output is coming from the same PyROS 'service' (an unix process maintained by PyROS) - so you would need to simultaneously monitor several process logs.
One option would be to write to log files. But, then, how far you can go with writing to SD card? It has limited throughput as well. Then you would create several files, which would need to be downloaded after the run and analysed in parallel. Not an easy job. All of this lead us to decide to create simple data gathering system - a simple telemetry library!
Ideas were like following:
- ability to define the structure of data
- ability to 'pump' larger amounts of structured data to the logging system
- ability to fetch data on demand from client/analysing software
- nice to have: ability to produce aggregate of gathered data for real time telemetry
So, here it is - small side project of Games Creators Club: GCC-Telemetry