do u mean the motors ?
if yes then there is a switch on OBAL to turn off PCA9685 board.
the different boards should not have issues in i2c, they have issues in RX only, so if you can read RX signals from the remote then 99.9% there is no problem in the rpi board.
My combustion engine donāt combust.
It looks like that you donāt understand that I only have problems outside of oval.
The board worked perfectly fine, the software as much I could test It on the ground looked good too. Just the plane I have donāt fly because the combustion engine donāt ignite. The motor/engine has problem
ic ā¦ glad u have no problems with OBAL.
A little question - arenāt the RPi GPIOs intolerant to 5V?
That means the RC inputs or even the i2c connections with the PWM driver or ADC could kill the Pi??
RC inputs works fine with my Orange RX DSM receiver.
for ADC you need to make voltage divider ā¦ you cannot measure voltage directly ā¦ you can use the output of power module cable .
RC inputs works fine with my Orange RX DSM receiver.
Interestingā¦! it seems that the ATMEGA on the Orange RX is powered from the same 3.3V rail that powers the non 5V tolerant RF chip. So the RC outputs are all 3.3V. I opened my Turnigy 9X receiver and found the microcontroller (TG79071, unidentified, cannot find datasheet) is powered from 3.3V as well. I always thought receivers output PWM at the provided BEC voltage. Not sure if this is the case for all receivers, though.
My concern with the PWM and ADC modules on OBAL is that they have the SDA and SCL lines pulled up onboard to 5V. The sensors have pull up resistors as well, to 3.3V. However, the PWM and ADC modules expose all I2C devices - including the Pi itself - to 5V. This should be solvable by removing the pullup resistors from these two modules.
They work fine with all RPI I used (Zero,Zero2,RPI4,CM4) ā¦ I even connected Arduino I2C to RPI directly and it worked great.
I got it working on breadboard and then on proto board. I used Drone Engage with Arducopter isolated on 2 cores. This is my first time making a quad, and using Ardupilot as well. So far I am really impressed with everything.
This quad is a temporary platform for learning and testing Ardupilot and OBAL. The hardware will soon be transferred to a VTOL quadplane. I will try to share updates.
Meanwhile I am getting too much voltage fluctuation on the battery reading from a Pixhawk power module, around 0.2~0.3V. My suspect is voltage rise due to resistance on the ground wire. I have not figured out a good solution yet.
1 Like
super !!
Thank you.
Please share your finding regarding the voltage and if the PCB routing needs to be updated.
Hi, @MHefny and thanks a lot for your FOSS design of this ardupilot platform! Its simple and cheap and could help against the annoying chip shortage and rising prices of the STM32Fxx chips.
I am wondering if you or any other one who use your design can give me any feedback on stability of the platform ?!
Did you every saw any unwanted reboots of the pi due to software (kernel or ardupilot) or hardware (e.g. pi wants very stable and clean power supply - otherwise reboot) or any other problems?
Also did you ever experience any filesystem corruption of your pi due to hard power cutoff?
Others (e.g. https://www.reddit.com/r/diydrones/comments/mrhylk/comment/ifl9oob/?utm_source=share&utm_medium=web2x&context=3) also describe that actually a lot of commercial products use SBCs as fligthcontroller, and i am wondering why this is not the case for hobbyists? Thus its intersting if you could share your experience on stability 
Thanks!
Hi @julled
Have had look the beagles platforms( green, black, blue and pocket)? This sbc are been used since 2016 with ardupilot.
Regards.
hi @juvinski i know they are there, but its hard to find specific experiences regarding stability.
Can you give some feedback on stability on beaglebones (offtopic of course) or OBAL?
Hi @julled
Iām using beagles since 2017 in several mapping planes and drones, and the only problem of stability was a bug by a faulty driver I wrote for a temperature sensor several years ago.
One important thing with Linux boards in my point of view is the load average, once if you have something demanding cpu you can have problems once any bottleneck can be pretty dangerous so for me this is the bigger concern and all new version or feature to be enabled demand a lot of tests before use in production environments. In the case of beagles, there is a discussion on the beagleboard.org related to a sucessor for beagle bone black, once beaglebone black was launched in 2015 and even now in 2023 is the same processor memory, but for me there are two major features in the beagles - the prus(real-time units) and the buses - but in 2023 a single core cpu is not enough.
There is the beaglebone ai but ia not clear of this board will be available in the market and the beaglebone ai-64 I believe is perfect for robots but not for uav - I received mine and the 64 bits architecture and the support for buses still in development.
Regards
1 Like
At the beginning of designing the board I used the 5V from the ESC it didnt like it, maybe because I was connecting 4 of them together. And that is why I added this circuit that shut down PCA9685 if RPI restarts.
But that was a powering issue that completely disappeared when I used a dedicated UBEC and not connect 5V of the ESC to the board.
Another thing is that I use cpu affinity. I found it useful when I run other software with AP such as DroneEngage, but in general I do not use it. For example RPI-WZ-2 with OBAL-GY-92 is running perfectly smooth and I never had problems with it at all.
A short answer for your question is that I do not have data about flying it for too long. I only left it on my desk working for a day but not actual flying which is very different. My objective of OBAL is to have a simple easy-to-build educational board for ppl. who wants to studying building boards for AP not to create a rock solid board.
I agree that Linux based boards is not the best option for FC, but unless you need processing power to calculate EKF and similar calculations that these type of boards are excellent at. But this on the other hand limit you in SPI & I2C you can use that is why I am trying to merge the two designs in what might be the next OBAL.
Hello,
I guess NAVIO was the best demonstration of a commercial product running on RPI.
Erle robotics was also a commercial venture but in all cases it seems the SBC based FC is now a dead end.
The reasons are mainly related to the difficulty of configuring such a platform as it requires a lot of knowledge to make it running fine (File System , Kernel, Process, I/O and so on). As a consequence, there are fewer people working on the development and support of these products.
This is why the FC-CC (Flight Controller- Companion Computer) configuration is more attractive as you can benefit from a very stable and well supported FC and you can attach many types of CC depending on the application. For example, I have built systems running RPI Zero for basic swarming up to Intel I7 for advanced Visual Slam systems.
Still, I consider experimenting with SBC type Linux FC was the best school for self teaching robotics in general and Drone FC in particular but you have to invest yourself into it.
2 Likes
Thanks for these indepth tips n tricks!
I also found in my tests that the PI need a dedicated DCDC converter, otherwise its not stable. So good to hear it also helped you.
Regarding affinity: Do you have experience if affinity for single cpu on a pizero2 or pi4 is enough for running APM reliably? Did you run any experiments on the responsiveness off APM on limited cores?
Also nice to see you are continuing in producing next level OBAL. Looking forward for getting this upstream!
1 Like
Yes I run OBAL on a single CPU and it ran safely but I tried it in doors for no more than 7 min flying.
I found some differences based on used sensors.
For example OBAL-9250 runs very well on RPI-Z. While OBAL-GY91 needs RPI-Z2 and then it runs even better. Actually the best combination so far is RPI-Z2 & OBAL-GY91
1 Like
I have used OBAL for outdoor flights on a Quad with excellent results. Testing was confined to my rooftop in the city, however, so I didnāt try AUTO or GUIDED modes.
Now Iāve installed it on quadplane and got acceptable or good enough hovers on Q modes with only the motors connected. But there is a problem now - the PCA9685 is doing 400Hz PWM . The analog servos should not be able to tolerate much more than 50Hz. The PCA has all its outputs clocked at the same rate if Iām not wrong, 400Hz in this case.
Can you suggest workaroundsā¦? Is it possible to use a separate PCA clocked at 50Hz? Iām currently thinking of using an external Arduino for converting the PWM outputs to lower frequency PWM, but Iām not sure how stable that would be.
1 Like
I have tried to connect the board to small blue servos and it was working ok.
I guess the ultimate solution would be using two PCA9685 one for motor and one for servos.