The easiest way to provide a defined work environment when organising a Hackathon around the NAO robot is to prepare a Virtual Machine with all software preinstalled (Choregraphe, git, documentation, Python, etc.). Personally, I use Mint Linux running in a Virtual Box (Ubuntu gives me this bad Google/Facebook feeling).
While installing Choregraphe is easy, you will quickly get blocked by the repeated disconnection of Choregraphe from NAO.
Normally, this indicates a firewall problem, but neither deactivating the firewall with “sudo ufw disable“, nor emptying the iptables defaulting it to “all open” with “sudo iptables -F“, nor explicitly defining “all open” rules with “sudo iptables -P INPUT ACCEPT / sudo iptables -P OUTPUT ACCEPT / sudo iptables -P FORWARD ACCEPT” helps preventing the disconnections.
Still, the reason is a port blocking problem. While Choregraphe is able to connect to a target outside the VM’s host operating systems, inbounding connections reaching the host systems are not reaching the VM’s guest system.
This leads us to the easy solution: defining a port forward rule from the host OS to the guest VM.
In Virtual Box, this is done via the VirtualBox main menu “Devices”, “Network”, “Network Setting”, Adapter 1, [Port Forwarding]. Here, we add the Choregraphe’s main ports (54010-540nn, depending how many instances you have running) and the most important: the NAOqi port 9559.
If you are not sure about the ports, simply display the debug log files in Choregraphe to make the concerned ports visible (see screenshot above).
Once the port forwarding confirmed, the connection with the NAO root should be stable, without even restarting the VM.