Network options

[explosivose]

There's a few networking arrangements that we could implement:

1. Connect as a wireless client on Eduroam
   Provides internet access for pi. Uncertain whether coderbot website could be reached from outside the university.
2. Connect as a wireless client on a router that is plugged into the student network
   Provides internet access for pi. Uncertain whether coderbot website could be reached from outside the university. If router is serving multiple robots there would need to be some configuring to allow outside access to each pi (i.e. different ports on the same public IP address on the router)
3. Setup pi as an access point with hostapd
   Pi internet access seems to be interfered while dnsmasq is running. Wireless devices can access coderbot website by connecting to the pi wi-fi access point (no access beyond wi-fi range).

Note that if the coderbot website is publicly accessible on the internet then we should implement authentication and research some security and vulnerability issues we might encounter with the pi. Much of the python code is executed as root which is necessary to access GPIO, apparently.

[explosivose]

Had an idea for a web-based hub that displays and directs to available robots. It wouldn't be too hard to implement with Flask and have the robots register with the website (it would probably need a static IP on the uni network or on a local network)

[danentwistle]

We talked to Ray from EESE IT office yesterday about our options.

Ray tells us he shall liaise with uni IT to grant us permission for adding our own wireless routers with a wired connection to the uni network (as per point 2. in this issue).

We prefer option 2 because

• it makes the activity portable (take the WLAN router and the robots anywhere, connect to the WLAN with a computer to access coderbot websites)
• also allows the activity to be accessible remotely as long as the robots are connected to the internet via the router