@Rowan-Dempster , we will go ahead and integrate the limited 32-bit ION buffer support into libmodal-pipe. Did you make any changes to my latest branch from a few days ago? If so, I can take whatever changes you have and do the final integration. If you have not made any changes (and don't have any suggestions), I can just finish it up from here.
Thanks again for your help!
Alex
Hi @Aaky ,
The documentation for the mini ESC states that we recommend using this ESC for drones 750g or less. It seems your UAV weight is around 1800g.
https://docs.modalai.com/voxl-mini-esc-datasheet/
I am concerned that the ESC may overheat (even though sustained current capacity may still be ok). Also, for larger motor like 2206, you may need to add a bypass capacitor to the ESC power ensure stable performance.
Have you performed tests of sustained hover thrust to see what the ESC temperature is like after several minutes of continuous "hover" thrust?
Alex
In order to debug the PX4 modules that run on the DSP side of VOXL, you should run voxl-px4 in interactive mode, such as:
systemctl stop voxl-px4voxl-px4 -dThen you should be able to run qshell vectornav ... command and see its output. If you just run px4-qshell from command line, the prints from the dsp do not propagate back to the user.
Another alternative is to use (sudo) mini-dm (on your linux host that is connected to VOXL2 via ADB) which allows you to see low level messages from the dsp (mini-dm is a tool that is available in Hexagon SDK).
Now, regarding integration of a new driver with the DSP, I am assuming you were able to enable the module to build for the DSP, but it's running correctly because the device is not recognized. This is because in order to use the DSP uart in PX4, you need to call voxl-specific functions to open, read, write on the DSP port. Please take a look how this integration is done in the gps driver : https://github.com/modalai/px4-firmware/blob/voxl-dev/src/drivers/gps/gps.cpp , specifically looking at #ifdef __PX4_QURT and similar conditionals.
Alex
@Rowan-Dempster , sure, that would be helpful. I don't see any issues with merging that in, since if we do it right, it will not affect 64 bit build at all and will only add limited support for 32 bit -- limited, meaning, for clients only, cannot allocate new buffers.
i will check with the team today to make sure we are all good, so perhaps you should wait for that.
Alex
@Rowan-Dempster , nice! I am glad it worked.
i think the issue here is that we have changed the struct definition (of the ion buffer type), which should not be changed for the 64-bit library. So until we hopefully mainline this, you can just manually copy the 32-bit libmodal-pipe.so into /usr/lib/ (while the original 64-bit version will remain in /usr/lib64). Did you try that?
For mainlining this, i think we will need to do a #ifdef 32 bit and insert the allignment dummy bytes as well as bypassing the ion allocation functions, which require libgbm.so.. You could try that change as well, just need to figure out how to detect 64 vs 32 bit in the few source files that we changed.
Alex
@leandro , documentation for M0187 has been updated to include the 3D CAD file :
https://docs.modalai.com/M0187/#3d-drawings
Alex
Hi @rpowerscat ,
You may be looking for these?
Will check availability and get back to you..
Alex
Hello @namanthaker,
We typically do not provide the register configurations for the cameras because the camera drivers may contain confidential information from other sources.
However, the IMX664 camera is integrated with VOXL2, which can be used for testing and experimentation.
By the way, the camera drivers for VOXL2 are not contained in kernel modules, but in sensormodule binaries, which are loaded by the camera pipeline (just FYI). I am not aware of any way of extracting the register settings from those binaries.
Alex
Hi @Rowan-Dempster ,
I made a few changes (based on your branches) to libmodal-pipe and the 32-bit tools and now it seems to be working without any run time errors from the test tools or 64bit camera server:
https://gitlab.com/voxl-public/voxl-sdk/core-libs/libmodal-pipe/-/tree/ion-32bit-test
https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-mpa-tools/-/tree/ion-32bit-test
The issue in libmodal-pipe was with a struct size difference for 32 / 64 bit systems.
Please note that when you build libmodal pipe, do not deploy the 64bit version to voxl2 as it will break things. Later we will need to fix this up so the struct padding is platform dependent.
voxl-image-repub is working now . I had to disable the FD caching due to a strange issue (segfault) when inserting into std::map. Did not investigate why that happened. Without duplicating the FD (using the original FD in the callback, everything works). Also the 32-bit version of voxl-inspect-ion-stream works as expected.
Feel free to test this out. If you don't find any more issues, we can try to mainline this change after cleanup. I am a bit concerned that std::map insert failed, but it is possible this is because i am using the latest voxl-cross to build the app, but my test board is running on old SDK (and there could have been a c++ runtime libs update sometime in the recent voxl-cross).
Alex
Hi @Rowan-Dempster, thank you. I will take a look today.
Alex
Hi @Aaky, can you please confirm which ESC you are using for this drone? This thread is related to the mini ESC, and i just want to make sure that you are not using that for the relatively heavy drone.
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
@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
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
@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:
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
to enable voxl-streamer and voxl-camera-server on startup, just use the following commands:
systemctl enable voxl-camera-serversystemctl enable voxl-streamerRegarding your question about thermal radiometric readings, i am not sure - can you please elaborate? The default post-AGC 8-bit mode sends a monochrome processed image. The pixel value is related to the temperature, but the image itself does not provide the mapping from pixel value to temperature. Also, not all Boson units support outputting radiometric data.
I don't have much experience with this aspect (and I don't think we have any Bosons with radiometric output capability). Looking at some FLIR help, it seems that you have to use the 16 bit output (well it's actually 14 bit) and turn on linear T output and then the conversion from RAW pixel value (16 bit) to degrees is simple : https://flir.custhelp.com/app/answers/detail/a_id/3387/~/flir-oem---boson-video-and-image-capture-using-opencv-16-bit-y16
If this is the case, then here is how this could be tested (high level steps - don't worry if you don't know how to implement them at this point) :
voxl-streamer to be encoded with h264 / h265.I have not actually tried that script (at the bottom of that help article) -- i wonder what would happen if i use it with a Boson that does not support radiometric output. Do you know?
I can help set this up if i can test it using non-radiometric Boson. It seems the conversion is straightforward, I could potentially add the support for this directly into voxl-camera-server.
Alex
Yes, QVIO only runs as a 32-bit app due to the nature of the library from Qualcomm.
I tried to build the voxl-image-repub application for 32 bit and got the following error:
/usr/bin/arm-linux-gnueabi-ld: CMakeFiles/voxl-image-repub.dir/voxl-image-repub.cpp.o: in function `main':
voxl-image-repub.cpp:(.text.startup+0x228): undefined reference to `pipe_client_set_ion_buf_helper_cb'
So it seems like the 32-bit version of libmodal-pipe does not support sending ION buffers.
I just checked with the team - even though we have not tested the ION buffer sharing in 32-bit environment, it should work. You could try to build libmodal-pipe library and enable ION support : https://gitlab.com/voxl-public/voxl-sdk/core-libs/libmodal-pipe/-/blob/master/build.sh?ref_type=heads#L76 .
Then you would need to install that new library into your docker container where you are building your app, as well as deploy to VOXL2.
BTW in order to build the tools in voxl-mpa-tools i needed to disable -Werror and comment out a few targets like voxl-convert-image and voxl-inspect-cam-ascii due to lack of 32-bit version of opencv.
So.. if you really wanted the QVIO app to use the shared ION buffers, you would have to go that route..
Alex