Posts made by rapit

Thanks for the answer, yes I already looked into the code. I was just wondering why the servers timestamp differs from the system timestamp. But then I will change the node accordingly.

Hey,
I noticed that the timestamps in the ros message header are always relative to boot time. Even if I synchronized the system time with the internet time or via chrony and restarted the services (dfs-server, voxl-vision-px4). Can I somehow get the system timestamps in my message? This is essential when being part of a larger ros network.

If it is intended like that, the best way would probably to replace the stamp with some rostime in the voxl node or is there some preferred way?

Thanks

Hi,
I tried the voxl-cam for the first time and all seems to be working fine except that px4 is not getting into position mode.

voxl-inspect-qvio prints reasonable poses, I can see the Odometry topic in QGC with 30 hz with x,y values not zero.

My EKF2_AID_MASK is 280 and with the same parameters and the voxl flight-deck I managed to start in position mode without GPS attached.

Problem seems to be that I cannot get values in LOCAL_POSITION_NED and nothing is being output on uorb top vehicle_visual_odometry in a nuttx console.

I made a cable to connect the pixhawk4 and the voxlcam, which is twice as long as in the old setup. The voxl-vision-px4 systemd service suggests that UART is connected, but maybe there could be some issue in sending the data?

Do you have any suggestions?

Thanks!

I had the same issue. Updating the voxl_mpa_to_ros package resolved it for me:

opkg update
opkg install voxl-nodes 

Hi @Chad-Sweet,
even though this is not public (yet?), I setup a docker running open-vins. It runs without problems but I keep getting fast divergent behavior. Do you happen to have a launch file / parameter settings for open-vins with good parameter estimates for the flight-deck platform? I am not sure if my I set the extrinsics correct. I thought it must be simply the inverse of the output of voxl-inspect-extrinsics as open-vins expect a T_C0toI matrix:

        <rosparam param="cam0_wh">[640, 480]</rosparam>
        <param name="cam0_is_fisheye" type="bool" value="true" />
        <rosparam param="cam0_k">[277.207560, 277.285144, 335.460288, 218.329580]</rosparam>
        <rosparam param="cam0_d">[-0.002486, 0.006832, -0.006556, 0.001300]</rosparam>
        <rosparam param="T_C0toI">
            [
                0.0, 1.0,  0.0, -0.015,
                -0.70711,  0.0, 0.70711, 0.00283,
                0.70711,  0.0,  0.70711, -0.0212,
                0.0, 0.0, 0.0, 1.0
            ]
        </rosparam>

Another possible reason would be badly calibrated imu noise values. A reference file would be really helpful.
Thanks!

Good news, I didn't know that Apriltags are already supported, maybe the docs should be updated.
I updated and all streams are working simultaneously in the new architecture. Thanks.

Hi,
I am trying to publish some stereo output from the flight deck via ros with running voxl_vision_px4 in the background.
As stated in your docs I tried yocto:~# roslaunch voxl_cam_ros stereo.launch is_cam_master:=false but the launch always fails.

ERROR: The requested frame_id(0) does not exist in the queue.
[ERROR] [1627501325.921901556]: GetImageData() Unable to get Frame data for id: 0 rc: -2
[stereo/stereo_nodelet_manager-2] process has died [pid 5056, exit code -11, cmd /opt/ros/indigo/lib/nodelet/nodelet manager __name:=stereo_nodelet_manager __log:=/home/root/.ros/log/e264a974-efdb-11eb-b918-d80f995591f7/stereo-stereo_nodelet_manager-2.log].

I think my id's are correct, if I stop voxl-vision-px4.service and set is_cam_master to true it works. It also works if I choose the stereo_merged.launch launchfile, even with voxl-vision-px4 in the background. Other combinations (hires, tracking) work as well so I am wondering if there is a technical limitation on this specific combination or is this supposed to work. I am still on version 2.3 as I need the Apriltag support.

Thanks!

Thank you Travis!

I made another cable today and it was recognized as usb3 device. I guess the quality of the first cable was too bad in the first place or I did a bad job switching the channels.

However, until now I did not manage to create a robust connection. The driver behaves wierd and especially in the docker container I was not able to use the bandwidth. This is probably usb-driver or device related so I will try to play with the kernel parameters.

Anyhow, in theory it now works, so thanks a lot! (Also for the writeup, probably others can benefit from that.)

I tried it with swapped SSRX/TX as you posted in the pinout graphic but unfortunately it is still detected as usb2 device. Any other thoughts? Do I have to adjust some config or should it work out of the box after swapping? Maybe the cable quality or my wiring skills are not good enough, I will try it again with another cable.

Thank you so much for the graphic and the table! I will see what I can do to rearrange an existing cable. Even "small" cables are hard to fit into the voxl mounted on the flight deck, so it is probably easier with a custom cable than with a "large and bulky" one.

Hi Travis,

thanks a lot for your effort!

I am not sure if I got it right.
@modaltb said in USB 3.0 Camera:

In order for systems to use the standard micro-b to type A female OTG cables, they need to do TX/RX swapping.

I thought this was exactly the difference between the standard OTG cables, which I used before and my second approach with the micro usb type a cable (which also seems to be quite unique).

Anyway , so the special thing about the Amphenol RUB30-0075 you mentioned are swapped TX/RX ? I couldn't find anything on that cable, do you have a datasheet / pinout or any tip where one can buy it?

If not, any chance I could purchase one from you directly?

Thank you!
Raphael

Hi,
quick question: I am trying to connect an additional USB-3 camera (Basler dart) to the flight deck. The camera has a usb3.0 micro-b port. I connected it with two high quality USB3.0 cables as follows:
(micro-b (camera) --- STD-A male) -> (STD-A female --- micro-b (voxl))

The camera was detected properly and worked, but lsusb -t showed it was only connected with usb2.0 (480M) and unfortunately the camera driver pylon timed out a lot.

Now I bought a micro-a male --- micro-b male cable similar to the one you linked in your docs to get super speed capabilities but now the voxl cannot detect the camera at all. dmesg doesn't show any output. I read that the port can be in host mode when using micro-a plug and in client mode when using micro-b. Why does it work when using micro-b but not at all when using micro-a?

Did you try the port with similar periphery? Are there additional pitfalls? Or did I just bought 2 bad cables?

Thanks a lot!

Thank you, it works now. I did not think about using my local mavros as connection link between voxl and QGroundControl.

I changed the port. The original issue was a binary installed mavros which crashed when using a gcs_url. So I thought it was a configuration problem but building mavros from source and running with your proposed configuration worked. Thank you again!

Raphael

Hi Chad,
thank you for the link. I did read section before but I could't see how it would help me as the port on the outgoing connection is still the same.

I just configured my base station ip in ggc_ip and secondary_qgc_ip (and en_secondary_qgc) and the connection to my ground control station is successfully initiated by voxl. But when I fire up mavros at my ground station, QGroundControl again loses the connection to voxl, so initiating "from the other direction" does not seem to solve the port conflict.

Hi,
I usually connect my QGroundControl (running on base station) to the voxl which in my unsderstanding "routes" the mavlink data from the flight core to my base station.

Sometimes I want to run a mavros instance not on the voxl but on my base station. I am not sure how to configure this node correctly in order to connect to the flight core using voxl as "wifi link". It works if I set the fcu_url param like that: udp://:14550:@VOXL_IP:14556 but then the link in my QGroundControl fails. I guess it is because both connections are running over port 14550. I have no idea how to set fcu_url and gcs_url`. Or do I have to install additional software on the voxl to route the packages?

Any help would be appreciated!

Nevermind, apparently I looked in the wrong places:

https://dev.px4.io/master/en/ros/external_position_estimation.html has the answer: EKF2_HGT_MODE must be set to vision to use the voxl odometry instead of the barometer. Closing this.

Hi,
I was wondering how I have to configure px4 to get the position estimate from voxl for position mode.

The connection to TELEM2port of my Pixhawk4 works, I am getting Odometry Messages when voxl-vision-px4 is running. I set the px4 parameter EKF_AID_MASK to 8 which is vision position fusion. I completely removed GPS from my drone.

When I inspect LOCAL_POSITION_NED messages I see the x,y coordinates from the odometry but the z coordinate is very off.

Any thoughts on that? Thank you!

Never mind, I updated all packages and reset all configs and it appears to work great. Maybe a misconfiguration somewhere else.

Thank you!

Thank you, with the correct config file for the tag size, the detected tag positions and rotations in voxl-test-vision-lib -a look quite accurate now!

Unfortunately, this had no impact on the vio, it is still not detecting any April tag correct and I get lots of:

...
WARNING, apriltag roll/pitch out of bounds
WARNING, apriltag roll/pitch out of bounds

But maybe this is not AprilTag related, as vio is reporting very high velocities, sometimes without any AprilTag visible:

...
T_body_wrt_local: 1738.20 882.29 453.10  RPY:  0.11 -0.09 -0.38  velocity: 39.93 42.38  3.43
VIO in failed state, restarting

Most of the time, all values are increasing without any movement until it is in failed state.

One more thing that comes to my mind, when I stream from the tracking camera (e.g. via the voxl_cam_ros node) it always streams an overexposed image:

I have to set the exposure parameter down to 0.05 to get a "normal" image. Maybe your vio uses the overexposed images as well leading to strange results.

Hi,
I tried the inbuild AprilTag feature today but I can't get it to work and I have no idea what is going wrong. I strictly followed the instructions from the walkthrough video / text.

The related config is very basic:

    "en_apriltag_fixed_frame": true,
    "fixed_apriltags": [
        {
            "tag_id": 1,
            "R_tag_to_fixed": [
                [0, -1, 0],
                [1, 0, 0],
                [0, 0, 1]
            ],
            "T_tag_wrt_fixed": [0, 0, 0]
        }
    ],
    "en_transform_mavlink_pos_setpoints_from_fixed_frame": true,
    "en_fixed_frame_pipe": false,

I set the tag-size to 0.16, as each square of the 8x8 tag grid is 2cm. A change of this parameter never had an effect to the detected tag position from voxl-vision-px4, which I find very strange.

When I run voxl-vision-px4 -p for debug odometry in fixed frame I get lots of out of bounds warnings. A "first-detection" with a followed position "reset" of fixed frame does not happen.

T_body_wrt_fixed: -0.00  0.00 -0.20  RPY:  0.00  0.00 -0.00
T_body_wrt_fixed: -0.00  0.00 -0.20  RPY:  0.00  0.00  0.00
WARNING, apriltag roll/pitch out of bounds

Sometimes, the tag is detected and the position is set to the fixed frame which is way off. This causes voxl-vision-px4 to diverge within a few seconds, even if the drone does not move at all. It crashes in the end of that process and resets the frame.

When I run voxl-test-vision-lib -a it prints

ID:  1 hamming: 0 margin:89.98 XYZ:  0.67  0.06  1.85 RPY: -0.51  0.25  0.25 hz: 13.6

which seams reasonable, even if there is a rotation offset (btw. This is in the frame of the camera right? The z-axis point 45 deg downwards away from the drone)

I recalibrated the tracking camera and reset the config multiple times. Any idea what else could be wrong here? Here is a picture of the setup, it is very similar to your walkthrough video, the voxl is about 1 meter away in y and z directions.

Any suggestions would be greatly appreciated!