Hermione’s “reach for the stars” was due to I²C errors; I suspected powewr brown-outs. Her regulator for the LiPo provided only 1.5A, so I tried her passively with mains PSU of 5V at 1A and 2.5A – the error was the same – shifted outputs from the IMU FIFO without any FIFO overflow. That suggested a interaction with the I²C with the Garmin instead. I rebuilt the cable with two UTPs (unshielded twisted pairs): SCL with Vss / GND and SDA with Vdd / 5V as per the PX4FLOW spec for long I²C wiring. I was stunned – it just worked, regardless of whether the 1A or 2.5A power supply was used, I no longer got any I²C corruption. Next step clearly is to test her live outdoors and check she no longer reaches for the stars.
I also had the bottle to let Zoe loose in the play room. She still hardly got off the ground on the first flight, so it’s not temperature drift. However, her second run was perfect, which reminded me that her first run was always cr@p for some reason. Here’s the stats for both. The stats are logging both accelerometer and Garmin / Camera distances. There’s such a tight correlation between the very difference sensors that I’m very tempted to turn the fusion on. Just a tad more bottle needed. The key one for each is the bottom left: how high was she according to the two sensor sources.
I thinkthat’s my courage bottle empty for the day. When it’s charged up tomorrow, I’ll take the sisters outside to test the above next steps.
Sorry it’s quieter than ever – the weather is against me testing the GERMS filter code, so I’ve been twiddling my thumbs. I have found some odd behaviour from the IMU that’s worth sharing.
The SMPLRT_DIV register sets how often the data registers are updated, and therefore how often the data ready interrupt goes high. Normally the ADC sampling frequency is 1kHz, and the data registers are updated at a reduced frequency defined thus:
1kHz / (1 + SMPLRT_DIV)
Setting SMPLRT_DIV to 0 should give data ready interrupt (DRI) at 1kHz; 1 should product 500Hz, 2 should give 333Hz etc etc.
But what I’m seeing is that with SMPLRT_DIV <= 3, the DRI happens at 250Hz. SMPLRT_DIV >= 3 work fine producing 250Hz (3), 200Hz (4), 166Hz (5), 143Hz (6), 120Hz(7), 111Hz (8), 100Hz (9) etc etc etc. Because I’m using the DRI as the clock for the code, that means 250Hz is the fastest I can use. That’s no problem really – that’s plenty fast enough allowing 4ms per sample during which I can run the motion processing, but it’s not a limitation that’s been documented in the specs
In passing I’ve fixed a rounding error bug in the pre-flight RTF period. Not important really, but actually fixing it was what exposed the DRI frequency limit.
I’ll upload to GitHub in the next day or so once I’ve had a chance to check I’ve not broken anything.
Just a quick apology for the musical references used in my posts. I suffer terribly from “ear worms”. While writing a post, quite often a relevant tune or lyric pops into my head, and gets incorporated into the post. If you’re interested, I’ve just tagged the relevant posts with “Ear Worm”. It was quite embarrassing doing the tagging, so many are from the 70’s or 80’s!
I hope I haven’t infected you with my ear worms; my apologies if I have.
I’ve been meaning for ages to get my turtle* project back up and running, and having put the quad siblings to bed for a while, I’ve finally had time.
By using a B+, I finally have enough GPIO pins to drive the stepper motors directly via 8 pins and mosfets rather than using the 74HC595 serial to parallel latch. That’s simplified the circuitry and software a lot. I’ve also turned the turtle into a WAP. Finally, I’ve swapped batteries from unregulated 2S LiPo to a 2.4A phone charger bank. This gives just about enough power – the 2.1V battery bank shown in the picture didn’t work – the motors drew enough current to trigger a safety switch in the battery.
I’m hoping to do a tutorial at the next Cotswold Jam, starting at a flashing LED and ending in a robot in 10 easy steps. In the meantime, just watch her boogie!
Turtle boogie! from Andy Baker on Vimeo.
P.S. For a giggle, watch the original “Yes Sir, I can boobie” on youtube.
*A turtle should really have a pen controlled by a solenoid to leave a trail as it wanders. A more useful implementation for the modern era would be as the base for a laser cutter, or 3D printer: consider attaching the stepper motors to a fixed base at 90° to each other independently manoeuvring a suspended platform around underneath a fixed position laser or molten plastic feeder? It’s only a different LEGO layout from what the turtles doing now.
In fact, my next project, piPlotter, has just been conceived, using the turtle motors to move a Raspberry Pi 7″ touch screen running a draw application with a stylus touching the screen to draw out the movement. More of a LEGO project than a RPi project, and a lot more fun as a result. Oh, and cheap too!
Installment 2 of updating Chloe to the Jessie level of Raspian: I2C and RPIO.
sudo apt-get install i2c-tools python-smbus pypy-smbus-cffi python-codebug-i2c-tether
- “i2cdetect -y 1” shows 68 and 77 for Drotek MPU9250 + MS5611
- Python development tools:
sudo get install python-dev
- Install and build RPIO
git clone https://github.com/metachris/RPIO.git
sudo python setup.py install
- Install and build my custom GPIO – I tried using the standard RPi.GPIO again, and it’s a lot faster than it was, but not quite fast enough
tar xvf GPIO-0.6.0.tgz
sudo python setup install
I’m now on my third case for my piPad, and it’s the best yet.
piPad cardboard case
Inside the cardboard box
My first was from Pimoroni, which was lovely, but offered no protection for the electronic behind. The support legs are rigidly fixed. Together this meant my piPad was not protected for carrying to the Cotswold Jam (tickets selling fast, buy them while you can).
Pimorino Touchscreen cover
The second was this one from Farnell.
Do not buy this case
Frankly I’m now embarrassed to say I bought it. Although it offered complete protection of the electronic, it is critically flawed in several ways:
- the only place to power it was via the Raspberry Pi micro USB socket; that’s not one of the three recommended ways i.e. power the display and RPi boards seperately (as per my cardboard box) or power the Raspberry Pi from the display board either via GPIO leads or a USB A to micro USB cable. I ended up doing much dremelling to open up the case to be able to access the display board micro USB socket and power both boards separately
- that done, I installed everything, but then I found that it was unstable – using the touch screen pushed the display over!
- finally, I _think_ the case puts too much pressure on the cables to the display and touch screen and may have damage my touch screen cable.
It’s now ‘out of stock’, perhaps due to the several support issues I raised with Farnell about this case’ completely inept design. I wouldn’t normally post about faulty designs on-line, but since I’ve had no response from them, I feel I must.
My advice, avoid like the plague!
I’ve watched the previous video loads of time now, not because of how well Phoebe is behaving, but because it really shows how much air those props have to propel downwards to take-off, hover and land. If you haven’t already, take another look and ignore Phoebe and watch the throws and paper being blown around. It gives a really good feel for how much power is involved to get one of these things off the ground.
We built this city on silicon!
Just thought this board looked a bit like a city with towers, houses and roads. In fact it’s a very-low-noise balanced-input audio amplifier with active ground-control (to Major Tom?) and RIAA filters for playing vinyl records. Records are not cut with a flat frequency response; the bass is reduced as is the treble so that the cutting / etching of the track stays within physical bounds. Playing a record requires the reverse filter at 3180us (50Hz low pass), 318us (500Hz high pass) and 50us (2120Hz low pass).
And yes, there was a deliberate decision to colour coordinate the components as long as quality wasn’t compromised – much like what I’ve done to Phoebe and Chloe recently. In fact, for Phoebe, Chloe and this PCB, colour choice has forced higher quality components to be used.
I call it creative OCD art and it gives me great satisfaction! Horowitz and Hill were not wrong with the name of their classic book.
Thanks again to the fab folk at Ragworm for producing the PCBs.
So the new IMU + PCB + Raspberry Pi passed the first stage by having no I2C errors. Next step was 0g calibration at a reasonable temperature which produced good results. Final step then is to power up the motors and ensure I’ve got all 4 to spin the right direction (testcase 1 in the code).
And that’s the next problem: the front right prop didn’t spin and the ESC didn’t shut up (they whine annoying when they are missing a PWM signal), suggesting something was wrong with the PCB or model A+ itself.
Now, I had 2 spare model A+’s and a very vague memory one was duff in some way, but I couldn’t remember which or how. So I swapped the model A+ over, and at the same time double checked the PCB and resoldered a couple of joints that looked slightly dodgy.
The result? All four blades now spin, but the I2C errors are back! It’s enough to drive you nuts – luckily I was nuts anyway just to take on this project!