Posts made by Zachary Lowell 0

Hi @jcai no there is currently no way to update the kernel outside of the SDK releases provided by modalAI (which can be found here: https://developer.modalai.com/). If you are on the latest iteration of the SDK, AKA 1.3.3 then you are on the newest kernel layer as well. I do not recommend touching the kernel as this is a sure fire way of bricking your machine and would leave this to us to figure out in a later relaease.

As for docker - you could just configure your router to give you the same capability of ip management that docker ipvlan supports. Or getting more hacky you could deploy a docker instance that contains a higher kernel version on the voxl2 and then share your network with the docker over net and ipc with the --net=host and --ipc=host flags and then run your ipvlan create call inside that docker image - almost a nested docker (which is more hacky and not best practice, but you get the gist). What version of docker are you on?

@Jeremy-Frederick I am assuming you are using the M0062 hat? If so there are no lights on the ethernet receiver on the board so there is not a way to confirm from a hardware standpoint that the ethernet receiver is getting a signal. Can you try updating to sdk 1.3.3?

@Vinny might have more answers on this as well to try out.

@craigphoenix said in VOXL2 Sentinel no wifi after new SDK:

How can I fix this?

Reply

@craigphoenix did you ever configure the SKU or MPA? This will basically enable and reset all the sdk with the proper parameters to match the system you are running. First run voxl-configure-sku and select the options that fit your sentinel. Then run voxl-configure-mpa which will reconfigure the mpa with the right sensors. From that point do a hard reboot and please let us know the status.

As for the WLAN not being picked up on - that is almost always hardware based and something might've come loose from the connectors. If it is easier paste a photo in here of the connection and the errors you are getting.

As for the Bus 12 not initalized error does that happen when you are at the esc installation part? If so, you successfully downgraded the kernel and the SDK but the sdk did not finish unpacking so you have a half baked setup on the voxl-sdk side.

LMK if this helps.
Zach

Hi @ctitus I actually have a PR sitting for mavcam manager that captures this exact use case:

https://gitlab.com/voxl-public/voxl-sdk/services/voxl-mavcam-manager/-/merge_requests/13

Please build this branch zach/mavlink_sys_id_update from source and then package and unpack the deb on the voxl2. Once there, if you have multiple VOXL2's all with different SYS_ID's from PX4, in the voxl-mavcam-manager.conf file, make sure you set the mav sys id in there to what it is on from PX4. Also set:

enable_auto_ip to False

and then set default_uri to the ip address assigned by the radio or modem you are using, not localhost or what is assigned from voxl-mavlink-server - so NOT 192.168.8.1, but the IP assigned by the radio or wifi module.

LMK if that works,
Zach

Also @Bernhard - you will never be able to view the encoded stream on voxl-portal, just on VLC or something like QGC. SDK 1.0 does support h264 which is software encoding though so innately it will be slower - does this work out the gate for you?

Hi @aashry voxl-camera-server with H265 support was implemented and included in an SDK past 1.0 - any reason why you are not upgrading to 1.3.3?

The other option is you mix and match versions of voxl-camera-server with your current SDK version, but odds are that will have quite a bit of conflicts as it is dependent on new versions of modalpipe and such.

Zach

@tahawaru also since you are running an RB5 and not a voxl2, the most recent SDK you are running is 1.1.3 which might have dependencies in modal-pipe or modal-json that are not transferable to the newest dev branch of voxl-mpa-to-ros2 causing some form of error somewhere in the pipeline.

Hi @wouter the reason this is happening is recently docker depricated their api v1 version and are only using v2 api calls now. Meaning the original voxl is not able to pull down pre made docker images. The solution around this is to build the docker image on a parent computer, tar it up via docker save, then push that to the voxl and run a docker load -i on the tar file.

You can follow similar to what we do in voxl-docker-mavsdk:

https://gitlab.com/voxl-public/voxl-docker-images/voxl-docker-mavsdk/-/blob/main/Dockerfile?ref_type=heads

@tahawaru I cannot say that I have tested this on an original rb5 board - just a voxl1 and voxl2 - works as expected on both. Have you build from source on the dev branch and installed that?

@Sarah-McMahon please clone down most recent main:

https://gitlab.com/voxl-public/voxl-docker-images/voxl-docker-mavsdk

Then follow the build instructions to build the voxl-docker-mavsdk docker instance and then push it to the voxl to load and run there. LMK if you run into any issues!

@Sarah-McMahon Hi! So it appears that as of this month Docker actually fully depracated their V1 API registry meaning that leveraging docker pull to pull down an already made docker image from dockerhub results in a 410 error (This is only an issue on the voxl1 as the docker instance is quite old and yocto doesn't play nice with the newer versions of docker). We are currently developing a quick fix that can build the voxl-docker-mavsdk image on a parent computer and then push that to the voxl1 on the m500 to leverage. Should hopefully have something in the next few days.

Thanks!

@tahawaru @nuallaino what happens when you build from source dev branch push the deb and then rerun the ros2 code base?

I assuming you are sourcing the right directory via voxl2:~$ source /opt/ros/foxy/mpa_to_ros2/install/setup.bash in both terminal windows prior to running the code base etc?

I am currently unable to reproduce your error and am testing on multiple voxl2's. What is the output of voxl-inspect-cam -a? Does it show the encoded frames working as expected? I have tried with both h264 and h265 on the voxl2 so far and have had no luck reproducing your error. I see you are on an rb5 flight though is that correct?

@tahawaru said in Issue with ROS2 set-up, Deserialization of UORB Topics:

No executable found

Reply

@tahawaru why are you trying to run px4_ros_com's package in general? The package pertinent to voxl-mpa-to-ros2 is voxl_mpa_to_ros2 - what is it exactly you are trying to do?

Is voxl-tflite-server capable of running ONNX models as well?

Hi @tahawaru looks like its just a type on the documentation I will update it:

Please just try running ros2 run px4_ros_com px4_ros_com - no s anywhere in site. Note this package is fully managed by PX4 - not modalAI and can be followed here: https://github.com/PX4/px4_ros_com

LMK if this helps,
Zach

@AndriiHlyvko said in voxl-camera-server more exif metadata bugs:

Just to give some context. I am trying to change the camera focal length in the exif data of the jpeg. But because somehow there are two Exif blocks in the jpeg only one is changes and not the other. There should only be one exif data block in the jpeg.

Here is an example output of the exiftool

Hm that is quite strange - I will do soem debugging - it could be that we are creating a new exif dataset to attach to the jpeg instead of filling the original. Will look more into it while you do as well! Let me know if you figure it out and I will do the same on the post here.

Hi @AndriiHlyvko we do not ever pipe in a JPG - the raw frame gets converted and saved as a jpeg in camera-server.

The android library does the image encoding to JPG from the raw frame. We pull the raw frame over the snapshot pipe via HAL3 and then we do the JPG conversion from the raw pipe.

https://gitlab.com/voxl-public/voxl-sdk/services/voxl-camera-server/-/blame/dev/src/hal3_camera_mgr.cpp?ref_type=heads#L281 --> Here is where the buffers get allocated

https://gitlab.com/voxl-public/voxl-sdk/services/voxl-camera-server/-/blob/dev/src/hal3_camera_mgr.cpp?ref_type=heads#L433 --> Here is where we define the parameters of the HAL3 pipe itself that is pulling the raw frames

https://gitlab.com/voxl-public/voxl-sdk/services/voxl-camera-server/-/blob/dev/src/hal3_camera_mgr.cpp?ref_type=heads#L2585 --> This is where the MPA is created to actually pipe the data, etc.

Specific to the actual jpg conversion, you are right in that it is abstracted out and we leverage an android library to handle the encoding into JPG, we just calculate the size of the frame and then feed that INTO the jpeg conversion - so the raw frame should be completely accessible to you.

https://gitlab.com/voxl-public/voxl-sdk/services/voxl-camera-server/-/blob/dev/src/hal3_camera_mgr.cpp?ref_type=heads#L1649 --> if you follow the meta and src_data parameter here, you will see where the raw data is coming in. We do leverage the libexif library after the encoding to unpack it and update the gps data as well - that can be found here: https://gitlab.com/voxl-public/voxl-sdk/services/voxl-camera-server/-/blob/dev/src/hal3_camera_mgr.cpp?ref_type=heads#L1483

Let me know if this helps!!
Zach

It is not a launch but a ros2 node itself - should just be ros2 run voxl_mpa_to_ros2 voxl_mpa_to_ros2, no launch script.

Zach

Ok @jmltt I fixed it - there was a giant conflict with versioning on px4_msgs and px4_ros_coms which was fun to deal with - anyways I have a branch waiting for approval to be merged into the most recent nightly and you can then pull the dev from the apt repository when it gets merged in - until then feel free to rebuild voxl-mpa-to-ros2 deb and install on your voxl2 from the branch zach/submodule update: https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-mpa-to-ros2/-/tree/zach/submodule_update

Cheers!
Zach

@jmltt said in Issue with ROS2 set-up, Deserialization of UORB Topics:

Not sure how many other messages this affects. Is this an easy fix on the dev side?

Reply

So @jmltt it looks like this isnt necessarily an issue with the branch itself as mainline px4_msgs also has the unaided_heading in part of the VehicleLocalPosition:
https://github.com/PX4/px4_msgs/blob/f90685f29174d4debfe31e22b4cf1412c3c16448/msg/VehicleLocalPosition.msg#L42C9-L42C24

Trying to figure out a way to remove it without recreating a new submodule - will hopefully have a fix soon.

Zach