@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.

@jonathankampia ,

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..

• I suspect FETtec ESC is using a pretty accurate xtal or accurate RC oscillator, so you should not need to calibrate the ESC
• You can check the current calibration by using QGC to control the individual motors to see at which command they start up and make sure that is very close to the same (typically around 1000us or a bit more)
• Additionally, you can spin up each motor with propeller at certain % power, lets say 20% or 30% and using an optical tachometer (RPM meter) to measure the speed of each motor
• Those are some sanity checks you can do without being able to calibrate and without having any ESC telemetry.

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

@saegsali , yes you are correct. Unfortunately, the USB port J3 is not populated on M0201 - I believe the decision was made to omit this connector due to some mechanical constraints, I am not sure.

A couple of things to consider:

• if you purchase this connector (BM06B-SRSS-TBT), you can solder it on and plug a USB connection in to it. I have not tried it, but I will. I don't see why it would not work, it should be powered from the USB port.
• if you have any other adapter (from FLIR, etc) which provides a USB port, the function should be the same and you could just plug that into the Boson and use it for the sensor configuration.
• we are developing a tool for communicating with Boson directly from VOXL2, but it is not yet to the point of performing full configuration. So you should try to use the GUI for the initial setup. Perhaps with the correct connection the GUI version 4.6 should work, otherwise there may be an issue with the GUI itself.

Alex

Hi @joseph-vale , i tested the python script from FLIR help site (Radiometry.py). I just had to modify it to use the correct USB and Video devices. The script ran find, but since my Boson does not support radiometric output, the reported temperature was like 70 degrees colder than it should be (reporting -50C at room temperature). Are you able to get correct temperatures with your device using this script?

As i mentioned before, there is a way of getting the image data from voxl-camera-server into python. I think it would be interesting to try running the same exact conversion and annotation code from the FLIR example. This would allow you to first check the temperatures using a USB connection and then check them using the VOXL2 pipeline.

I am going to set up an example that that uses pympa (python wrapper for MPA) to get the 16bit data from Boson and plot + convert it to temperature using the reference code.

Alex