@MHefny have you ever tried to connect OBAL to BlueOS?
I watched the recent presentation at APM Dev conf and it looks very promising for usage in combo with OBAL:
I think this could make a very nice userfriendly platform for development!
1 Like
I watched this video for BlueOS, and it looks impressive. However, I’d also like to draw your attention to DroneEngage. With OBAL board, you can now integrate DroneEngage on a single board without requiring a Raspberry Pi 4. This means you can use the more compact Raspberry Pi Zero 2W for video streaming over the internet. Additionally, OBAL board supports onboard video recording, although this feature is still in the planning phase for BlueOS. DroneEngage is a modular system that is managed by a communicator module. This allows developers to create modules in any programming language, including Python, Node.js, and C++, and integrate them into DroneEngage.
2 Likes
What sort of code modifications will be required to use two PCA9685s? It seems pretty involved.
Does your STM32 OBAL project support multiple output groups at different frequencies, like the STM32 based autopilots?
I just tried the blue servos, I was hesitant before, but it seems to work fine at Arduplane’s 490 Hz. Maybe slightly more jitter. It is way beyond spec, however, so I’ll leave it powered for long durations to be sure and see if I can fly with it.
Thanks.
There is a test version where I use STM32 instead of PCA9685 … The idea is to make a hybrid board where RPI makes calculations and STM reads from sensors. check this article for more details. My current status is that I have succeeded to migrate all sensors to STM32 I just kept the IMU on SPI directly connected with RPI. Maybe in future I can make use of ExternalAHRS feature in Ardupilot to add extra IMUs.
2 Likes
Great article @MHefny.
Some time ago I read somewhere about a raspberry/clone with a RP2040 integrated and the communication between both was using a shared memory, have you take a look on this ?
Thank you.
pls share this link if possible.
I find one of them - but I believe is just a concep for while, and according to diagram is using uart interface.
2 Likes
I connect “IMU9250 - breakout GY-9250 via SPI” like this
when i wire it like this and use the command “sudo i2cdetect -y 1” the raspberry pi is not getting any devices
But when I wire it this way, the Raspberry pi recognizes the connection to the module
did i install something wrong here. Because when I run Arduplane I always get the message “Config Error: Baro: unable to initialise driver”
OBAL is connected to IMU via SPI bus which will not appear when you execute i2cdetect -y 1
You need to also to have a BARO connected via i2c, or define in code HAL_BARO_ALLOW_INIT_NO_BARO in #elif CONFIG_HAL_BOARD_SUBTYPE == HAL_BOARD_SUBTYPE_LINUX_OBAL_V1
Hi Mohammad,
I have an OBAL board with RPI zero and i’m trying to get RC input work but without success.
I have compiled the RCInput test too and no signal was recognized from my flysky fs-ia6b pwm output.
Can you tell me what can be wrong and could you please show me the way to try to fix the problem ?
Make sure that RCIN_RPI_CHN_NUM is set to 8 not 1.
if RCIN_RPI_CHN_NUM is set correctly and ports are working and soldering is fine then it should work.
if you have programming skills try to check values of _process_pwm_pulse at RCInput_RPI.cpp
Checked everythings you suggested, radio signal still not detected!
Added printf message before and after _process_pwm_pulse at RCInput_RPI.cpp at line 660
Nothing logged in my console.
This is a mystery !
I think there is something wrong in the parameter setting but seems no one can help me in what to check.
UPDATE:
I found the issue but i really dont know why it happen.
May be there is a bug in ardupilot code ?
i try to explain:
RCInput_RPI.cpp file , line 522
(please pay attention at the comments between code lines)
void RCInput_RPI::init()
{
uint64_t signal_states(0);
#if CONFIG_HAL_BOARD_SUBTYPE == HAL_BOARD_SUBTYPE_LINUX_ERLEBRAIN2
_version = 1;
#else
_version = UtilRPI::from(hal.util)->get_rpi_version();
// HERE MY BOARD IS RECOGNIZED AS 1 BUT SEEMS TO BE NOT CORRECT
_version = 0;
//BECAUSE IF I FORCE IT TO BE 0 THE RADIO SIGNAL NOW WAS DETECTED LIKE A CHARM
#endif
set_physical_addresses();
Analizing the code in set_physical_addresses() function :
if (_version == 0) {
// 1 & zero are the same
dma_base = RCIN_RPI_RPI1_DMA_BASE;
clk_base = RCIN_RPI_RPI1_CLK_BASE;
pcm_base = RCIN_RPI_RPI1_PCM_BASE;
} else if (_version == 1 || _version == 2) {
// 2 & 3 are the same
dma_base = RCIN_RPI_RPI2_DMA_BASE;
clk_base = RCIN_RPI_RPI2_CLK_BASE;
pcm_base = RCIN_RPI_RPI2_PCM_BASE;
} else if (_version == 3) {
dma_base = RCIN_RPI_RPI4_DMA_BASE;
clk_base = RCIN_RPI_RPI4_CLK_BASE;
pcm_base = RCIN_RPI_RPI4_PCM_BASE;
in fact, it seems evident that the raspberry pi zero is initialized correctly if this value is 0 and not 1.
Off course i can force it to 0, but i’d like to know more about.
Any suggestion?
1 Like
If this is the issue then I guess the origin of the problem might be in _check_rpi_version_by_rev in libraries/AP_HAL_Linux/Util_RPI.cpp because this is where the app identified the model of RPI.
if you are using Raspberry_Zero then the return version should be _version=0
if it is recognized as RPI2&3 then there may be a problem in this function.
Please share your finding.
Thank you.
Well, after checking that below how i discovered:
the function _check_rpi_version_by_rev() detected the chipset version reading the file
/proc/device-tree/system/linux,revision
from the binaty content of it the function extact the 3rd byte
if (fread(revision, 1, sizeof(revision), fd) == 4) {
cpu = (revision[2] >> 4) & 0xf;
shift by 4 and 0xf
my chipset is a BCM2835 and is correctly detected but after that there are this strange code block
if (_rpi_version==0) {
_rpi_version=1; //RPI-Zero
}
et voilà, my correctly detected SOC with correctly detected _rpi_version = 0 become 1 !!
Really strange.
1 Like
yes this line of code is correct…
if (_rpi_version==0) {
_rpi_version=1; //RPI-Zero
}
_rpi_version is returned in get_rpi_version()
and for historical reasons RPI-zero is handled same as RPI-1 without differentiaing between them.
Below is the function I have … and it is compatible with the line you mentioned.
It seems it has been updated so it is no longer compatible.
It looks like a bug
// Physical addresses of peripheral depends on Raspberry Pi's version
void RCInput_RPI::set_physical_addresses()
{
if (_version == 1) {
// 1 & zero are the same
dma_base = RCIN_RPI_RPI1_DMA_BASE;
clk_base = RCIN_RPI_RPI1_CLK_BASE;
pcm_base = RCIN_RPI_RPI1_PCM_BASE;
} else if (_version == 2) {
// 2 & 3 are the same
dma_base = RCIN_RPI_RPI2_DMA_BASE;
clk_base = RCIN_RPI_RPI2_CLK_BASE;
pcm_base = RCIN_RPI_RPI2_PCM_BASE;
} else if (_version == 4) {
dma_base = RCIN_RPI_RPI4_DMA_BASE;
clk_base = RCIN_RPI_RPI4_CLK_BASE;
pcm_base = RCIN_RPI_RPI4_PCM_BASE;
}
}
this project looks awesome. it can replace complex wires for companion computer and FC. integrated board. awesome.
3 Likes
Hi @Niki ,I broke Pi Zero while trying to fixing another Pis.
The issue is a convention one - either /proc/device-tree/system/linux,revision numbers(0-3 according to chip used) or Pi numbers(Pi1,2,3,4 except Pi0 should be treated as Pi1) will work but both will need to be used consistently, both in the peripheral drivers and where we read the ID.
@MHefny and I are discussing it here: HAL_Linux: fix RPI Check by HefnySco · Pull Request #23943 · ArduPilot/ardupilot · GitHub
this PR has been approved it is in the master mode and should be included in coming releases