After flying the Crazyflie for a couple of days with the Joystick shield based remote control I figured an alternate user interface based on a Wii Nunchuk could be interesting. (It might also make the Crazyflie easier to operate for novice pilots). After a couple of hours coding I have a proof of concept Netduino based Crazyflie Nanocopter Wii Nunchck remote control unit.
Initially the nanocopter was difficult to fly, bouncing up and down (thrust control issues) and swaying side to side (roll & pitch control issues). After some digging I found that every so often the Wii nunchuk (my cheap clone) would return a buffer full of 0xFF or 0x00 bytes. The 0xFF case had been handled but not the 0x00 one. I added a second test into the GetData method (around line 335) to catch the 0x00 scenario and this appeared to fix the problem.
cnt = 0;
for (int i = 0; i < inputBuffer.Length; i++)
if (inputBuffer[i] == 0x0) cnt++;
if (cnt == inputBuffer.Length)
The nunchuck accelerometer provides roll and pitch, the joystick is for thrust and yaw. The first version of the CrazyFlieWiiChuckV1.0 is pretty basic and I have intentionally reduced the maximum roll, pitch, thrust and yaw values to make it easier to fly. (Need to set the Grove Base Shield to 3V3 for my code to work)
Currently I only calculate offset values for thrust & yaw. After a couple of test flights some visual indication of the pitch and roll values from the nunchuk would be helpfull.
I wanted to connect the remote data acquisition nodes directly to the server using their baked in nRF24L01+ support. On the server end the Crazyradio 2.4 Hhz nRF24LU1 USB dongle looked ideal. After some initial positive results I found that the CrazyRadio firmware had been implemented in a way that made it not suitable for my application. (I even considered downloading the BitCraze development VM and building my own custom firmware)
After spending a few hours trying to get the CrazyRadio dongle working I looked at my Crazyflie Nano QuadCopter sitting on the bookshelf.
Then I realised what I really needed is a more portable Crazyflie remote control unit so I didn’t have to unpack my laptop. So two nights later I have a proof of concept Netduino based Crazyflie Nanocopter remote control unit.
I used the NRF24 CrazyFlie emulator to debug my project. No doubt stopping me crashing my Crazyflie many times while debugging.
The Joystick shield has to be modified to work with the common Netduino nRF24L01 libraries which use interrupts rather than polling.
The joystick on the shield is for roll and pitch, the external joystick is for thrust and yaw. The first version of the JoystickShieldnRF24l01V1.0 is pretty basic but I’ll try and enhance it over the next couple of posts.
A fortnight ago I purchased two shields from Embedded Coolness for a couple of nRF24L01 based projects (quadcopter & robot control system) I’m working on.The shields were very reasonably priced and took roughly 10-15 minutes each to assemble.
// we need to call Initialize() and Configure() before we start using the module
_module.Initialize(SPI.SPI_module.SPI1, Pins.GPIO_PIN_D7, Pins.GPIO_PIN_D3, Pins.GPIO_PIN_D2);
_timer = new Timer(SendMessage, null, new TimeSpan(0, 0, 0, 1), new TimeSpan(0, 0, 0, 1)); }
private void OnSendSuccess()
So according to cuno and co NetMF is a viable processing platform for a quadcopter. I was worried about the GC and it looks like as long as I’m really careful about allocating memory (strings, buffers etc.) I should be okay. It will be like writing code for embedded micro controllers (V25 & HC11) in C not long after I left university,
I had been considering using the Quadcopter IMU to drive the execution of the orientation and stabilisation algorithms. The MPU 6050 has an interrupt output which can be configured to trigger when there is data available to be read etc.
I had read discussions about the maximum frequency which the Netduino & the NetMF could cope with and just wanted to check for myself. For this test I assumed that the PWM outputs (once initialised) consume little or no CPU and that with only an InterlockedIncrement in the interrupt handler that these would be the maximum possible values.
I used the onboard PWM (D3) to drive an interrupt (D1) and then had a background thread display the number calls to the interrupt handler in the last second. The button (D4) in the picture above allowed me to increase the frequency of the PWM output in 100Hz steps. The desired count and actual count where displayed using Debug.Print and the .Net Microframework deployment tool