(You can check the progress (and a copy of this post) on my blog.)
Finally, after some DHL delivery trouble the boards arrived.
After watching a few tutorials I immediately tried soldering the most difficult part – the MPU9250 chip. Turns out – if you don’t have the right flux type it’s impossible. I managed to ruin 2 boards in the process and broken 1 chip…
Notice the PCB changing color next to the IMU I2C pins and the ‘dry’ look. The pin header holes are also darker than the others due to the heat.
2 days later my new flux came: Chip Quick SMD291 ordered from farnell. This time it went much better as I was able to solder 2 chips in 5 minutes, from the first try. The trick is that tacky solder flux doesn’t evaporate from the hot air and keeps the chip floating while the solder melts (and prevents oxidation). When the solder flows, the chip kinda snaps into place and that’s it. In my first tries I used a flux pen that dried immediately and the friction between the chip and the PCB was greater than the solder surface tension – preventing the chip from snapping into place.
So this is the board almost complete, except for the ADS1115 ADC that didn’t arrive still:
The last few days I spent trying to get the RF4463 chip to respond on SPI1. I expected surprises and I got them:
- first of all, activating SPI1 on a RPI3B results in boot times of 2 minutes due to an interrupt issue with the UART driver. Solution: disable the bluetooth and use ttyAMA0 instead of ttyS0
- next I simply couldn’t get the chip to respond at all. 2 days I spent on this until I went back to the schematic thinking the wiring is not ok. Then I realized that the chip select is connected to CS2 which is GPIO 16 but the SPI1 overlay I used uses GPIO 18 as CS. Duh! Solved by adding
- that’s it – it works now
In the last moment I added 3 WS2812B RGB LEDs thinking that I will be able to drive them with PIGPIO. I didn’t check the datasheet closely enough to see that they need PWM impulses in the order of 0.5ns whichare way below the resolution of the library.
So today after soldering the LEDs I realized that I cannot drive them. Desperate, I turned to the schematic and saw that by sheer luck I connected the LEDs to GPIO 13 – which happens to be the hardware PWM channel 1. Yaay – exactly what this library needs.
So I downloaded the lib, configured it on DMA channel 4 and PWM channel 1 and ran it and voila! It works with <1% CPU usage:
So now I have almost all the hardware working – the dual IMUs, the Baros, the RF chip and most importantly – vital for a 2016 multirotor – the LEDs.
I have 6 unpopulated left to give away (for free of course, shipping covered by you) if someone is interested!
So now – back to software. The RC is coming along nicely.
Comments
@Patrick - absolutely no interference so far. I tested with an UBLOX Neo6 GPS module and even with the new camera on I still have a strong fix. I still have to post the measurement data but didn't have time to get to it.
@Alex, I thought about porting ardupilot for this board but I don't really have the time to do it and it's low in my priority list.
One other option I keep thinking about is wrapping the entire ardupilot as a node in silkopter. This way silkopter will act as a HAL structure for ardupilot and provide it with the sensor inputs. The advantage of this (for me at least) is that I would still be able to use all the sensor filtering silkopter has right now (which is very flexible and visual) and I'd be able to extend ardupilot with existing nodes in silkopter (like HD video streaming, servo gimbals, support for my custom TX system etc).
It's a lot of work though...
I am interested? I know you will be using your own flight stack but you should also be able to get it setup as its own board in ardupilot. I am still waiting for them to flesh out the dev guides on adding new supported boards. I have been inching along on a custom project due to this.
Hello,
Looking at the picture, I see that you have removed the USB & Ethernet connectors from the RPI, and added straight header connectors for the USB. It is a clever alternative to reduce the footprint of the autopilot, my question is: How does it perform , did you experienced any interference problems, considering that these are not shielded cables ?
Best regards