[Updated the PCB/SCH with the latest version:
- added a diode for the LEDs to drop the voltage from 5V to lower so the input (3v3) is lower than 0.7 VCC
- fixed some parallel traces on the top and bottom of the board
- broken out i2c on another pin header]
I started working on a custom FC board for silkopter and soon I will receive the first PCBs.
It's meant to be used as a Raspberry PI HAT and all the software (silkopter) runs on raspbian.
The board is 2 layout and can be printed (I hope, still didn't receive them yet) using DirtyPCB for ~30e for 10 boards. It was developed with the free version of eagle (hence the 2 layer limitation) in the past week.
Eagle schematic and PCB layout are on github
My goal with this board is to have solid, long range RF integrated into the board, add sensor redundancy and experiment with SMD as a side quest.
Sensors:
- Dual MPU9250 9-axis IMU, one on SPI and one on I2C. They will both perform @1Khz
- Dual MS5611 barometer, one on SPI and the other on I2C @100Hz for both
- ADS1115 16bit ADC for current/voltage sensing
- Input for a serial GPS like any ublox (3.3V signal)
- Input for a serial sonar like MaxSonar. Works both with UART and RS232 signals (normal or inverted, 3.3V both)
RF:
- Either a RF4463F30 board (-126dBm sensitivity, 1000kbps, 30dBm power)
- Or a RFM22B board (-126dBm sensitivity, 256kbps, ~20dBm power)
Outputs:
- 6 PWM. I plan 4 motors and 2 for gimbal
- 3 RGB leds (NeoPixels or WS2812b)
A skilled developer could adapt Arducopter to support this board in 1-2 weeks. The trickier part would be the RC part to make it use the RF board instead of a classic RC receiver.
I'm also developing a custom RC system with a Raspberry PI, a touchscreen for FPV digital video (800x480 resolution, 2000kbps), a 3 axis gimbal for yaw/pitch/roll and a motorized slider for thrust control.
I'm working now on the component selection and schematic.
The build log is here.
Feedback is welcome, it's my second PCB ever and my first one with SMD and especially a QFN package.
Comments
Thanks for the code and your help on setting it up
Silkopter environment is quite interesting and powerful,it is part of my toolkit as of now :-)
Might give it a try on my MiniZee as well !!
Email sent. You have instructions there. If anything fails let me know pls.
Cheers
Well this is an offer I cannot refuse !!!
This is my address: patrickpoirier51@gmail.com
Thanks for your help on this issue that is affecting the whole DIYer community.
You'd have to build the entire thing... I can send you the binaries though and a in 10 minutes you should be able to get it running.
You need the 'brain' (raspberry pi binary) and the 'gs' (running on an ubuntu)
They both have to be on the same network.
Let me know if you need this, I can prepare it in 10-15 min and send it by mail.
You'd be able to test these sensors:
ADS1115 (i2c)
MaxSonar (serial)
MPU9250 (i2c & spi)
MS5611 (i2c & spi)
Raspberry pi camera
SRF01/02 (i2c)
UBLOX (6/7/8 serial & spi)
Great !!
I guess I did not digged deep enough ;-)
It is not a coincidence, I received 4 defective units so fare and most are related to bad quality of reflow, and other DIYers also got this issue, This is why I have to rework all the modules I receive, so I am looking for a simple standalone code that I could use for test the SPI. I can use a probe, but the best is using real code on a test system so I dont have to dismantle my working drones all the time. Is there an easy way just to start just the ms5611 as some kind of standalone, or I have to build the complete Silkcopter?
Best Regards
@Patrick, the code for the MS5611 is here: https://github.com/jeanleflambeur/silkopter/blob/master/silkopter/b...
The same class is both for i2c and spi, the code differences are minimal. For the SPI wiring, check the schematic in the first post.
Regarding the photo you posted in the other thread with the unsoldered pin for the MS5611 carrier board, don't know if it's a coincidence or not but I had issues with the same pin in my board. I used solder paste and somehow that pin needed several passes of hot air to solder. Not sure why, maybe it has more thermal inertia due to internal connections or something.
In any case, that particular pin has to be connected to VCC (pin 1) or GND (pin 3) to select either SPI or I2C. If the connection is loose and the pin is floating you'll get comms issues.
Let me know if you need any help with the chip/code.
Cheers!
Thanks , and by the way, your Blog is really interesting and the Silkopter is a very interesting project , I'm a follower now :-)
On a complementary subject, I am working in resolving the bad MS5611 carriers (GY-63) that we receive defective since a couple of months from China (Banggood & AliExpress). Look here for some insights: ms5611
It seems the the defective problem is a global issue , I am still trying with alternative suppliers but so far it seem that there is only one manufacturing source that is producing non working GY-63 modules on the SPI bus == I2C is working.
I saw that you reported on the raspberry forum here , that you had a working code for ms5611 with SPI.
For testing and ultimately resolve this issue, I would be interesting trying your code. I looked on your github, but couldn't find it. You can PM me on this if you are interested to provide code, or simply publish the info if that is ok with you.
Best Regards
I have an old RPi A and I will test with it. I really doubt CPU usage will affect PWM timings as the signal is generated without any CPU help. It's just the DMA peripheral cycling through a pre-programmed linked list of transfers.
What does require the CPU is changing the PWM value (reprogramming the DMA list) but if that is the case, the quad will have bigger issues. The load for changing the DMA list is minimal, probably similar to sending a few bytes through I2C.
The real issue should be with bandwidth. If memory is saturated the DMA will have to wait for its turn. This should not happen with normal UAV software as they don't really transfer hundreds of megabytes per second.
In any case, I will test on the old Pi to see when things start to get nasty.
BTW - the MiniZee is a really nice build.
OK , If you happen to have a Zero or an old Pi on hand , give it a try , this way you will be certain that the multicore does not affect the results.
A reminder for the I2C, we had a lot of issues with the line loading on BBBMini when experimenters started adding devices on it. The design guide requires to use pull-up resistors on the lines (2 - 4 kohm) and this is especially needed if you plan to get a satellite board with sensors on it.
Cheers
I will definitely test with all four cores loaded 100% and some memory intensive workload as well. Next weekend probably.
For my next build I'll definitely use PIGPIO for PWM output, serial bitbanging for the sonar input and also to sample the CPPM.
P.S. I'm not really french... JeanLeFlambeur is just a character from a book. What happened in Nice is monstrous. I really hope those affected find some closure and that I never get to see news like that..
-
1
-
2
-
3
of 3 Next