I think you are close.. sure, if you want to share the diff or make a fork of the repos, I will try it out.
Alex
I think you are close.. sure, if you want to share the diff or make a fork of the repos, I will try it out.
Alex
@remill libusb doesn't use cmake. It uses autogen.sh, configure, make, etc. These are standard Linux build tools. If you enter a query such as "How do I build libusb on Linux?" into Google and check AI mode it will provide you with all the steps.
@Rowan-Dempster , yeah that is going to be a problem.. I don't think we have a 32 bit version of libgbm.so for VOXL2. This library is used for allocating the ION buffers.
The next thing to try would be to remove the buffer allocation part from the 32-bit build. Actually receiving and reading the buffer does not involve libgbm. the client just gets a FD, which needs to be mmap'ed and used. (this would remove ability to allocate new ION buffers, which you actually don't need on the client side).
I just commented out the following from the library CMakeLists:
#list(APPEND LIBS_TO_LINK gbm)
#list(APPEND all_src_files src/buffers/gbm.cpp)
and here are the errors:
/usr/bin/aarch64-linux-gnu-ld: CMakeFiles/modal_pipe.dir/src/buffers.cpp.o: in function `mpa_ion_buf_pool_alloc_bufs':
buffers.cpp:(.text+0x10c): undefined reference to `allocate_one_buffer(mpa_ion_buf_t*, int, int, unsigned int, unsigned int)'
/usr/bin/aarch64-linux-gnu-ld: buffers.cpp:(.text+0x184): undefined reference to `init_buffer_allocator()'
/usr/bin/aarch64-linux-gnu-ld: CMakeFiles/modal_pipe.dir/src/buffers.cpp.o: in function `mpa_ion_buf_pool_delete_bufs':
buffers.cpp:(.text+0x24c): undefined reference to `delete_one_buffer(mpa_ion_buf_t*)'
/usr/bin/aarch64-linux-gnu-ld: buffers.cpp:(.text+0x2a0): undefined reference to `shutdown_buffer_allocator()'
You could try replacing those functions with a fatal print statement "not implemented". Maybe that would work?
Alex
@remill
You can also add a FetchContent CMake declaration that will build your library during compilation. Here is an example for yaml-cpp
include(FetchContent)
# Fetch yaml-cpp from GitHub
FetchContent_Declare(
yaml-cpp
GIT_REPOSITORY https://github.com/jbeder/yaml-cpp.git
GIT_TAG yaml-cpp-0.6.3
)
# Disable yaml-cpp tests
set(YAML_CPP_BUILD_TESTS OFF CACHE BOOL "" FORCE)
set(YAML_BUILD_SHARED_LIBS ON CACHE BOOL "" FORCE) #cross 4.0 quits the chat if building static
FetchContent_MakeAvailable(yaml-cpp)
# Confirm target exists
if (TARGET yaml-cpp)
add_library(yaml-cpp::yaml-cpp ALIAS yaml-cpp)
endif()
install(FILES
${yaml-cpp_BINARY_DIR}/libyaml-cpp.so
${yaml-cpp_BINARY_DIR}/libyaml-cpp.so.0.6
${yaml-cpp_BINARY_DIR}/libyaml-cpp.so.0.6.3
DESTINATION ${CMAKE_INSTALL_LIBDIR}
)
@Nitin-Varma-Vegesna said in GPS for Starling2:
I got the compass sensor missing error for my Starling2, and I think it's an issue with the GPS. I want to buy a new GPS for the Starling2 ASAP, and I didn't see it on the products on the website. Is there a way for me to do that?
1 Reply Last reply a day ago Reply
@Nitin-Varma-Vegesna https://store.3dr.com/mini-gps-ublox-max-m10s/ <-- this is the gps that comes default with the starlings.
To clarify, our current platforms are shipped with voxl-open-vins-server as the default VINS solution; however, QVIO is still available (SDK 1.6.2).
@Nitin-Varma-Vegesna If you are just flying in manual or altitude hold modes then those shouldn't be an issue.
Here is something i tried, you can try as well. You are right, there is a background service that may be taking over, I think i found how to disable it:
systemctl disable QCMAP_ConnectionManagerd
systemctl disable qti_pppd
systemctl disable qtid
rm /lib/systemd/system/multi-user.target.wants/QCMAP_ConnectionManagerd.service
rm /lib/systemd/system/multi-user.target.wants/qti_pppd.service
rm /lib/systemd/system/multi-user.target.wants/qtid.service
#edit: instead of disabling the above 3 services and removing the entries from `multi-user.target.wants`, it seems you can do the following:
systemctl mask QCMAP_ConnectionManagerd
systemctl mask qti_pppd
systemctl mask qtid
# you may want to disable dhcpcd as well, but i dont think that is strictly necessary:
systemctl disable dhcpcd
Now, set up static connection:
#create a new network interface file
vi /etc/systemd/network/10-eth0.network
[Match]
Name=eth0
[Network]
Address=192.168.xx.xx/24
Gateway=192.168.xx.1
DNS=8.8.8.8 1.1.1.1
enable networkd
systemctl enable systemd-networkd
Then reboot voxl2...
I think if dhcpcd is enabled, it may first take over the interface, but then networkd takes it back.. For example, here is the log from networkd when dhcpcd is enabled:
...
Dec 10 06:01:00 m0054 systemd-networkd[1126]: dummy0: Gained carrier
Dec 10 06:01:00 m0054 systemd-networkd[1126]: dummy0: Gained IPv6LL
Dec 10 06:01:11 m0054 systemd-networkd[1126]: eth0: Gained carrier
Dec 10 06:02:13 m0054 systemd-networkd[1126]: eth0: Gained IPv6LL
Dec 10 06:02:13 m0054 systemd-networkd[1126]: eth0: Configured
Dec 10 06:02:13 m0054 systemd-networkd[1126]: docker0: Link UP
Dec 10 06:02:21 m0054 systemd-networkd[1126]: eth0: Lost carrier
Dec 10 06:02:36 m0054 systemd-networkd[1126]: eth0: Gained carrier
Dec 10 06:02:38 m0054 systemd-networkd[1126]: eth0: Gained IPv6LL
Dec 10 06:02:38 m0054 systemd-networkd[1126]: eth0: Configured
and the log with dhcpcd disabled:
...
Dec 10 06:02:13 m0054 systemd-networkd[1126]: bond0: Link is not managed by us
Dec 10 06:02:13 m0054 systemd-networkd[1126]: sit0: Link is not managed by us
Dec 10 06:02:14 m0054 systemd-networkd[1126]: eth0: Link UP
Dec 10 06:02:38 m0054 systemd-networkd[1126]: eth0: Gained carrier
Dec 10 06:09:56 m0054 systemd-networkd[1126]: eth0: Gained IPv6LL
Dec 10 06:09:56 m0054 systemd-networkd[1126]: eth0: Configured
Dec 10 06:09:56 m0054 systemd-networkd[1126]: docker0: Link UP
Can you try and see if that solves your issue?
Alex
@Rowan-Dempster, the errors above seem like print formatting issues, but i understand that there could be some others. If you want to try to resolve those and see if there are any more significant errors, I can help.
We do not plan to update QVIO to use ion pipes, mainly because QVIO only supports a single camera input, so the savings from going to ION buffers for a single camera is going to be very small. The majority of savings came from the buffer caching policy, which I pointed out in the previous email. Another reason is that we are now focusing on Open Vins, which does support multiple cameras.
We do plan to fix the buffer caching policy so to remove this extra cpu usage for the appropriate MISP outputs. The work is ongoing in the branch i mentioned above.
Are you running multiple instances of QVIO, one for each camera?
Alex
@mkriesel , a few tips..
Regarding the ESC PWM range, the procedure is documented for VOXL2 IO board : https://docs.modalai.com/voxl2-io-user-guide/#how-to-perform-esc-calibration -- please go over that and make sure you did it correctly.
Alex