IP socket communications

I'm putting together this simple C#-based Windows Forms control app to interact with the quadcopter (written in C++, compiled for ARM). The app will send the flight control commands (e.g. manual input from the Xbox One controller, or waypoints once I have GPS integrated), and receive telemetry data from the quadcopter (e.g. inertial measurements).

At this point I've opted for socket-based IP communications (I'll decide if it's worth it to migrate to long range RC based protocols later) as it's easy and straightforward. There are 3 sockets, each used on its own thread to take advantage of the 4 cores on the Pi

1. Beacon socket thread: broadcasts a UDP message, every 1 second, advertising the IP of the quadcopter on the network. Used by the control app to detect and connect to the quadcopter.
2. Incoming command socket thread: TCP socket - in order to insure reliability of connection - used to receive commands from the Xbox controller and the control app. This thread will update a singleton class that contains the flight state and current controller input, accessible by other threads.
3. Outgoing telemetry socket thread: UDP socket - don't care if packets get lost, just need to minimize overhead. This socket will be used by the control thread, the same that samples the sensors and adjusts the motor speed. I might also run it on a separate thread and queue the telemetry data points to send in a FIFO - whichever has the least overhead on the control loop.

Everything has been implemented in a class inheriting a virtual interface so, assuming long-range RC protocols like Xbee are not too different, I should be able to switch implementation without having to touch the rest of the codebase.

So far everything works fine :-)

As usual the code is on bitbucket. I'll make the control app source public as well soon.

The control app UI is now used to plot the Xbox controller input and send it to the Raspberry Pi. The Pi then only takes the throttle value and changes the PWM signal on channel 0 of the PCA9685.

The charting section of the UI will also be used to plot incoming telemetry. It's going to be useful to calibrate and implement the right low-pass filter on the inertial unit.

 

The next step will be to interface with real motors once I receive them and the ESC/battery.