Well, tangerine actually!
With the IMU FIFO code taking the pressure off critical timings for reading the IMU, a huge range of options have opened up for what to do next with the spare time the FIFO has created:
- A simple keyboard remote control is tempting where the QC code polls stdin periodically during a hover phase and amends the flight plan dynamically; ultimately, I’d like to do this via a touch screen app on my Raspberry Pi providing joystick buttons. However for this to work well, I really need to add further sensor input providing feedback on longer-term horizontal and vertical motion…
- A downward facing Ultrasonic Range Finder (URF) would provide the vertical motion tracking when combined with angles from the IMU. I’d looked at this a long time ago but it stalled as I’d read the sensors could only run at up to 100kbps I2C baudrate which would prevent use of the higher 400kbps required for reading the FIFO. However a quick test just now shows the URF working perfectly at 400kbps.
- A downward facing RPi camera when combined with the URF would provide horizontal motion tracking. Again I’d written this off due to the URF, but now it’s worth progressing with. This is the Kitty++ code I started looking at during the summer and abandoned almost immediately due both to the lack of spare time in the code, and also the need for extra CPU cores to do the camera motion processing; Chloe with her Raspberry Pi B2 and her tangerine PiBow case more than satisfy that requirement now.
- The magnetometer / compass on the IMU can provide longer term yaw stability which currently relies on just the integrated Z-axis gyro.
I do also have barometer and GPS sensors ‘in-stock’ but their application is primarily for long distance flights over variable terrain at heights above the range of the URF. This is well out of scope for my current aims, so for the moment then, I’ll leave the parts shelved.
I have a lot of work to do, so I’d better get on with it.
I put the camera out last night as the hedgehog food seemed to have vanished. Sadly not due to a hedgehog:
Bovril, one of our cats
Dave, Bovril’s nemesis
A very brave mouse!
A very brave mouse!
and yet, amazing.
So in that last video of a ~10s flight, Phoebe drifted about 1m when she shouldn’t have. To me, that’s amazing; to you, that may be underwhelming. So here’s why you should be amazed. Basic school math(s):
distance = ½ x acceleration x time² ⇒ plugging in the numbers above says she was accelerating at 0.02m/s² (2cm/s²) instead of zero to travel 1 meter in 10 seconds.
Gravity is roughly 10m/s². The accelerometer is set to read up to ±4g. So that’s a range of 8g or roughly 80m/s²
So 0.02/80 * 100 = 0.025% error or a ±8 error value in the sensor range of ±32768.
Now the critical part – the sensors are only rated at 2% (±655) accuracy, and yet I’m getting 0.025% or 80 times that degree of accuracy.
And that’s why I don’t think I can get things very much better, whatever I do.
There is a slight chance that when the A2 is released (sounds like that’s shifted to next year now), I may be able to run the sampling rate at 1kHz without missing samples (I’ve had to drop to 500Hz to ensure I don’t miss samples at the moment).
Other than that though, she needs more sensors:
- camera for motion tracking (!blind)
- ultrasonic sensors for range finding (!deaf)
- compass (!disorientated)
- GPS (!lost)
- altimeter (!scared of heights).
but they’ll also need an A2 for the extra processing. So this is most definitely it for now.
I’m taking a break from PID tuning today, as I need a rest. Instead I had a little tinker with getting RaspiCam to work. The drone is already flashed with the latest (June 2013?) image, and the wires connected so all I needed to do was to run raspi-config to enable the camera, and then do “raspistill -o test.jpg”.
All I got error messages suggesting I checked the wires. The wires were good, but somehow I’d managed to detach the connector between the camera and it’s board – the little gold rectangular one – I didn’t even realize it was a connector, but there it was flapping around loose. A gentle push reattached it, and it must have worked as another try with raspistill led to this – the box the drone was sitting on:
Drone camera’s first shot
I’m already half way through the code which can spawn off raspivid, so once I’ve got the PIDs sorted, hopefully I’d be able to record videos too!
Take a drone, a PiCam, a case, and a 30cm cable, and look what you get!
Spot the plastic surgery?
What a pretty little nose she has! Here’s a close up. I hope I don’t break it!
I’ve bought a PiCam case to protect the delicate cable and electronics the other day. I fiddled and faffed to get the camera in safely and securely without damaging the cable or camera itself, and then finally realized that it was really simple and elegant once you know how.
There are two things you need to know: firstly there is some flexibility in the case; be gentle but it does bend; secondly, there are two slots in the back piece which the board clips into perfectly – this is the bit I missed at first.
Don’t faff like I did trying to ensure the camera poked through the hole in the front while attaching the back – that’s completely the wrong way round. Instead, clip the board into the slots in the back, feeding the cable under the tiny slot in the base; once the board and cable are safely secured like this, just clip the front on and Bob’s your Mo’s Bro!
In preparation for getting a camera board to sling under my drone, I’m in the process of tweaking a RaspberryPi Model A, and designing my own variant of the PiBow case to match – although in doing so, I’ve found much broader use…
For the RPi changes, I’ve removed the A/V socket, and replaced the GPIO pins with an IDT connector so I can lose a couple of layers in the Model B PiBow. That’s now complete – removing the A/V connector wasn’t too bad, but removing the GPIO pins was a right PITA – more on that in another post. Here’s the end result.
For the PiBow, I wanted a cross between the Model B and Model A PiBows: thinner like the model A, but with bolts in the corner like the model B so it could be a direct but thinner replacement for the Model B Ninja PiBows I’m using at the mo on the drone and its RC. Primarily this is to reduce the weight, centre of gravity, profile and power consumption of both.
In the end, I had to compromise, and took 2 layers out of the model B, and sealed up the A/V socket, and opened up the GPIO hole to allow the larger GPIO connectors. I got a local laser cutter company to produce this from my Pibow001-AB3. Here’s what it looks like….
PiBow A + PiBow B cross
Note the addition of the IDC connector isn’t mandatory – there are 90 degree sets of pins available, and they were my first choice, but for the connectors on the ribbon cable, the 90 degree pins weren’t quite long enough. They would still take the single wire pin connectors though if that’s what you’re after.
SkySpy – a self-piloted quadcopter (eventually!)
The blades started spinning yesterday for the first time, so I thought I’d show what I’ve been up to after the turtle. Although the blades are spinning, it’s not left the ground yet. There’s a lot of work to simply get takeoff, and then have it level out without hitting something in the room (i.e. me!). Currently it’s a drone – control is all within the Python script integrating the I2C PWM and motion detectors. I have plans to add a second RPi as a controller, but currently I just rlogin to kick off the blades. A ctrl-C on the python shuts them off pronto!
The body itself is a DJI Flamewheel 450 – the kit provides the body, motors, cabling and ESCs, leaving it to me to provide the control parts.
The Spy in the title comes from the RPi camera it will carry when available.
P.S. An ESC is an electronic speed controller. It takes a PWM input, with a carrier frequency of up to 400Hz, and in each 2.5ms cycle, the signal is high for 1 – 2ms. The ESC then takes this signal, converts it to a 3 phase equivalent (120o separation), feeds the result into 3 H-bridges which control how long the 30A, 11.1V power is fed into each motor stator per cycle. Note the current through the coils is always at maximum, but it is the time it is fed which controls the overall power and hence blade spin speed. The ESC gets inductive feedback through the same cables driving the motors allowing it to fine turn the power it applies.
In my original whitterings about doing a quadcopter, I though the ESC could be replaced by Pis – ignorance is bliss! Having learnt the above, I’ll leave the ESCs to the people that know how and leave the Pi to do PWM, acceleromer and operator control function!