weixin_39812577
weixin_39812577
2021-01-10 03:39

Vision estimate

This PR adds support for vision position estimates coming in via MAVLink. They are published and the INAV estimator subscribes and reads them.

NOTE: Set the parameter CBRK_NO_VISION to 0 to disable the circuit breaker for vision estimates (right now we default to vision input OFF).

None of this is tested, in particular the INAV changes might need a few printfs and testing until the runtime results make sense.

该提问来源于开源项目:PX4/Firmware

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答

81条回答

  • weixin_39812577 weixin_39812577 4月前

    I can't find a reason why the vision estimate should deteriorate flow. I'm merging this now. If you are experiencing problems, please ensure that neither your tracker (e.g. SVO or the multi sensor fusion) nor the ROS bridge send any vision_estimate updates after they have lost track. The symptoms you're describing could be partially explained if they would keep repeating old data.

    点赞 评论 复制链接分享
  • weixin_39812577 weixin_39812577 4月前

    What is the password for VisionEstimatePX4?

    点赞 评论 复制链接分享
  • weixin_39559750 weixin_39559750 4月前

    user: vision password: px4

    点赞 评论 复制链接分享
  • weixin_39559750 weixin_39559750 4月前

    Regarding the update: I was checking the Readme again and, as is, it should be ok. Right know I have some other working pose algorithms. I will probably send them compressed to you also to test in your side. The only thing that needs update now is mavros. Just clone master (https://github.com/vooon/mavros).

    To test the pose estimation pkgs, /mavros/src/plugins/vision_estimate.cpp must be edited, depending what kind of message you are subscribing (can be a /tf or a pose). If doesn't work with /vision subscribed, add prefix / (/vision).

    Also, to test the px4flow and gcs_image_bridge plugins, clone mavros_extras (https://github.com/vooon/mavros_extras).

    点赞 评论 复制链接分享
  • weixin_39812577 weixin_39812577 4月前

    Sorry that I missed this earlier! The readme is GREAT! I've copied it on this page: http://pixhawk.org/dev/ros/desktop

    Could you maybe extend it with the update instructions, rather than just having them here? Please shape them in a way that we don't have to keep updating the image, but people can just run the appropriate commands to update.

    点赞 评论 复制链接分享
  • weixin_39559750 weixin_39559750 4月前

    OK. I will register in the http://pixhawk.org/dev so I can directly edit them.

    点赞 评论 复制链接分享
  • weixin_39559750 weixin_39559750 4月前

    Already made some mods in the tutorials. Going to have some more info soon.

    点赞 评论 复制链接分享
  • weixin_39812577 weixin_39812577 4月前

    The improvement is already visible. Please note that its not clear from the context in which directory to run commands like git clone xxx and that you might want to explain that git clone is a one-time command and updates can be pulled with git pull origin master.

    点赞 评论 复制链接分享
  • weixin_39553653 weixin_39553653 4月前

    instead if manual git cloning use wstool (it really save time).

    点赞 评论 复制链接分享
  • weixin_39559750 weixin_39559750 4月前

    Did some cleaning now ;)

    点赞 评论 复制链接分享
  • weixin_39559750 weixin_39559750 4月前

    can you please change the file name of the VM from px4_ros_virtualbox.zip to px4_ros_vmware.zip? Just for convenience 8)

    点赞 评论 复制链接分享
  • weixin_39559750 weixin_39559750 4月前

    , , , Is the call going to happen? If yes, at what time, since that appears that it has to happen tomorrow? The options I see are only two: 10:00AM and 4:00PM @ GTC.

    And, will it by Skype, Hangout, any other?

    Set your thoughts :)

    点赞 评论 复制链接分享
  • weixin_39812577 weixin_39812577 4月前

    Yes, final date here! http://doodle.com/iinyqpeicq4ina9s

    Sorry for the latency.

    点赞 评论 复制链接分享
  • weixin_39559750 weixin_39559750 4月前

    Where's the call going to happen? On Hangouts? Please add me to the call via < nuno DOT msm DOT 1 AT gmail DOT com > (you already sent me the invitation to my hotmail mail). Thanks!

    点赞 评论 复制链接分享
  • weixin_39812577 weixin_39812577 4月前

    You have been added (see your inbox). Its a G+ hangout.

    点赞 评论 复制链接分享
  • weixin_39559750 weixin_39559750 4月前

    Yes it was to my Hotmail inbox. Please send it to my Gmail: < nuno DOT msm DOT 1 AT gmail DOT com >

    点赞 评论 复制链接分享
  • weixin_39553653 weixin_39553653 4月前

    Please add me too, but i answer in chat.

    2014-08-11 12:48 GMT+04:00 TSC21 notifications.com:

    Yes it was to my Hotmail inbox. Please send it to my Gmail: < nuno DOT msm DOT 1 AT gmail DOT com >

    — Reply to this email directly or view it on GitHub https://github.com/PX4/Firmware/pull/1041#issuecomment-51755194.

    点赞 评论 复制链接分享
  • weixin_39559750 weixin_39559750 4月前

    Update: http://pixhawk.org/dev/ros/desktop now has new MAVLINK msg API to setpoints, since https://github.com/vooon/mavros/issues/97 is done and closed.

    点赞 评论 复制链接分享
  • weixin_39606137 weixin_39606137 4月前

    Can you please check above issue? I've been trying for the last two days without avail. Flow position estimation works fine before the first vision packet is received. After it is received though, flow has very very slight effect on the position estimate. The filter keeps diverging when flow data is available. Movements have slight effect.

    Also, I was seeing wild values on vx, vy, etc. in LOCAL_POSITON_NED, even though my vision weight parameter was set to 0. Commenting out the velocity correction from vision fixed this, but I'd like to understand why it was happening in the first place...

    Can you confirm the flow issue?

    点赞 评论 复制链接分享
  • weixin_39926749 weixin_39926749 4月前

    I can check the velocity weight thing tomorrow. I don't have PX4flow so can't test this issue.

    Commenting out what line exactly fixes the issue? Also what parameters did you get to zero?

    Set the following three to zero to disable vision totally. INAV_W_XY_VIS_P INAV_W_XY_VIS_V INAV_W_Z_VIS_P

    If the flow has no effect when vision is running you might need to change the weight parameters. The flow weight gets changed by numerous parameters. Mainly INAV_W_XY_FLOW and an internal variable w_flow. If the flow is not accurate it decreases the flow weight automatically as show here https://github.com/PX4/Firmware/blob/vision_estimate/src/modules/position_estimator_inav/position_estimator_inav_main.c#L579 . Otherwise it get sets a few lines up and affected by INAV_FLOW_Q_MIN parameter. I don't know exactly what this is for without looking into it more.

    点赞 评论 复制链接分享
  • weixin_39812577 weixin_39812577 4月前

    I merged this branch with master, but debugging the actual operation is something that you folks need to get a hold of. The upside is that this is also an investment into understanding filters and sensors better, so it will help you build additional knowledge. Inav is relatively compact and accessible compared to a full Kalman filter and a great tool to learn the basics.

    点赞 评论 复制链接分享
  • weixin_39559750 weixin_39559750 4月前

    I will do some tests and let you know of the results. In the meantime try what said and zero the vision parameters. It may be possible that local_origin for px4flow estimates and vision estimates are out of sync.

    点赞 评论 复制链接分享
  • weixin_39812577 weixin_39812577 4月前

    Hi all - where are we standing with this? The diff of this PR is so tiny that it should be a solvable problem. Are there further testing results? Are you confident that the involved ROS bridges to their transformations correctly?

    点赞 评论 复制链接分享
  • weixin_39559750 weixin_39559750 4月前

    Still in tests in this side . Wanna make sure that the ROS side is working ok. Still in doubts regarding the ENU<->NED conversions but I think that everyone will get to some common point. Will have to test the vision+px4flow conjunction part also.

    点赞 评论 复制链接分享
  • weixin_39606137 weixin_39606137 4月前

    I have been busy an and got no time for additional testing. I can confirm perfect bench tests with just vision XY. Copter ready to fly. Just waiting for batteries (Post is sooooo slow).

    Using flow and vision hasn't been working. The problem hasn't got anything to do with bad code in this PR in particular. I think we have a logic problem, and scaling issues between flow and vision. I added a system of reducing vision weight if we have good flow estimate, and it improves things slightly, but more work is needed. Some structural change in INAV might be needed.

    My offboard EKF fusion of flow data is getting on so I will not need to use INAV after that stage , but most of the others depending on INAV, so will be trying to fix.

    Can someone please briefly explain how INAV works to fuse GPS and flow? I will look into the code soon, but a short intro would help.

    Kabir

    点赞 评论 复制链接分享
  • weixin_39613824 weixin_39613824 4月前

    If you are familiar with Kalman filter, then it's easier to explain this way: INAV is KalmanFilter with fixed gains (INAV_W_ parameters are gains) :) It has some magic to adjust weight according to estimater errors (e.g. EPH/EPV for GPS), but it's magic and will never be so good as Kalman. But it's simple and works :)

    点赞 评论 复制链接分享
  • weixin_39812577 weixin_39812577 4月前

    Hi all - I would propose to set up a call - please register here for times you are available next week: http://doodle.com/iinyqpeicq4ina9s

    It seems like we're missing a small delta here and coordinating with voice might be more effective to resolve this.

    点赞 评论 复制链接分享
  • weixin_39559750 weixin_39559750 4月前

    We will possibly have and little problem regarding availability, since he lives in Australia.

    Update: Seems not :D

    Can we agree an hour then?

    点赞 评论 复制链接分享
  • weixin_39926749 weixin_39926749 4月前

    Hi guys I am only really available on Monday with the times indicated. I leave on Tuesday for a 4 week vacation in UK and southern France.

    I just haven't had the time I thought I would to progress on this project (quite frustrating). Although I am really keen to see it to the next stage. My bench tests have proved successful and it seems a matter of flight testing for me. Although I have no px4flow so can't test this.

    点赞 评论 复制链接分享
  • weixin_39559750 weixin_39559750 4月前

    I think this is a matter of understanding the weights of each sensor in the inav estimator and getting the right values to them. Since GPS/Flow fusion was already working, I think Vision/Flow should also work. If could give us a flowchart of the algorithm, it would be helpful also.

    : your participation can be considered almost "demanding" :P since you are responsible for the mavros bridge.

    点赞 评论 复制链接分享
  • weixin_39812577 weixin_39812577 4月前

    I tried your VM, but there are multiple issues with it, and I would appreciate if you could fix them for the next revision: - Did you export it properly? Because my VirtualBox version refuses to import it. If you did export it correctly, you should obtain an .ova file (see the File -> Export Appliance menu) - Please ZIP it, do not use RAR. Its not really more efficient and in contrast to ZIP none of the systems supports it by default. RAR is not an useful exchange format. - Please try the import process (which would partially have uncovered these issues) and provide instructions how to 1) import 2) run 3) within the VM (please provide the login and password there as well): How to run a set of ROS packages to talk to the autopilot

    That would be a baseline to get anyone started. On top of that instructions how to upgrade the various software packages would be great, because that needs to be done regularly.

    Thank you for this effort!

    点赞 评论 复制链接分享
  • weixin_39812577 weixin_39812577 4月前

    I forgot to add the link - I would appreciate if you could put instructions here: http://pixhawk.org/dev/ros/desktop

    点赞 评论 复制链接分享
  • weixin_39559750 weixin_39559750 4月前

    , 1. The VM is for VMWare and not for VirtualBox, as I told you when I sent it to you. 2. Can do that, but it will take much time to load it again to the Cloud; but no problem at all. 3. What do you mean with import process? 1)/2)/3)All the doc is in a readme file on the desktop ;)

    The mavros should be updated also. I have to clean the VM again if it has to be sent on .zip, since I'm been using it to develop my project. Readme on the VM must be redone also probably.

    点赞 评论 复制链接分享
  • weixin_39812577 weixin_39812577 4月前

    Thanks - I must have missed the comment 8). 1. It runs fine in VMWare 8) 2. I already re-packaged as ZIP (see page) 3. Ok - we only need the instructions how to update it then.

    点赞 评论 复制链接分享
  • weixin_39559750 weixin_39559750 4月前

    Well while this is not solved, I turned back to commit 4598bf5487651cc465e4220a9c44198933d66b80, which is mavros release 0.6.

    点赞 评论 复制链接分享
  • weixin_39553653 weixin_39553653 4月前

    And 0.6 solve this problem?

    点赞 评论 复制链接分享
  • weixin_39559750 weixin_39559750 4月前

    Yes ;)

    点赞 评论 复制链接分享
  • weixin_39559750 weixin_39559750 4月前

    Still, the vision_estimate pkt is just sent once, as the local_position keeps the same (with z changing just a bit) and getting a FCU: [inav] VISION timeout

    A quick note: I get after that

    [ WARN] [1406049004.167230062]: WP: timeout, retries left 2 [ WARN] [1406049005.168045292]: WP: timeout, retries left 1 [ WARN] [1406049006.168308038]: WP: timeout, retries left 0 [ERROR] [1406049007.168651455]: WP: timed out.

    which may be the thing you are trying to resolve somehow. Still don't know why is trying to get the waypoints as I didn't define any.

    点赞 评论 复制链接分享
  • weixin_39812577 weixin_39812577 4月前

    I assume you all have seen Glenn's firmware pr with some improvements?

    点赞 评论 复制链接分享
  • weixin_39553653 weixin_39553653 4月前

    It is strange. I hope i can verify px4 issues at sunday.

    点赞 评论 复制链接分享
  • weixin_39559750 weixin_39559750 4月前

    Not really , where's that PR?

    Anyway, said that it's improvements won't change any behaviour related to this issue of the plugin just sending the estimate once, only the LED part. Have you tried it already in the VM?

    Update: Ok I found it. Never mind ;)

    are you planning to accept the PR soon? Don't think it will correct the above problem but at least it's a cleaner implementation for testing.

    点赞 评论 复制链接分享
  • weixin_39559750 weixin_39559750 4月前

    Well I have news: using a /pose msg and listening to that pose works ok -> ok meaning that it constantly sends the msgs. The /tf in other way seems to just send the message one time (even though it seems to be listening and updating the tf ok).

    Note: may be related with the data rate? I dbg using the printf that suggested and the tf pose is extremely fast compared with the pose that is coming from a visual odometry algorithm I'm running. Don't know if it may be related but it's the only thing I could compare for now.

    点赞 评论 复制链接分享
  • weixin_39559750 weixin_39559750 4月前

    Solved!!! The rate was the problem! Added a delay in the TF listener and problem solved. I'm will try to find the best delay to use in this case I will report it back! ;D

    点赞 评论 复制链接分享
  • weixin_39559750 weixin_39559750 4月前

    would you mind to write the listener like this:

    
    void tf_listener(void) {
            tf::TransformListener listener(pos_nh);
            tf::StampedTransform transform;
            ros::Rate rate(50.0);
            while (pos_nh.ok()) {
                // Wait up to 3s for transform
                listener.waitForTransform(frame_id, child_frame_id, ros::Time(0), ros::Duration(3.0));
                try{
                    listener.lookupTransform(frame_id, child_frame_id, ros::Time(0), transform);
                    send_vision_transform(static_cast<:transform>(transform), transform.stamp_);
                }
                catch (tf::TransformException ex){
                    ROS_ERROR_NAMED("position", "VisionTF: %s", ex.what());
                }rate.sleep();
            }
    }
    </:transform>

    This will add a delay. I tried 10 as the pose listener but it seems slow. Tried 100 but seemed to fast and it jumped. with 50 it seems to slowly update the pose till it reaches the /fcu marker. Give some tries on other delays and see what do you get ;) Maybe now I'm able to try some POSCTL. would you mind accepting the pr of so to do some flight tests with a cleaner code? Thanks!

    点赞 评论 复制链接分享
  • weixin_39553653 weixin_39553653 4月前

    Just added tf_rate_limit parameter to master. You can copy these files to 0.6.

    点赞 评论 复制链接分享
  • weixin_39559750 weixin_39559750 4月前

    Thanks ! So we don't follow different paths, when you have PX4 in hands, please have a look why the connection breaks when position lock is gained.

    点赞 评论 复制链接分享
  • weixin_39926749 weixin_39926749 4月前

    Sorry for delayed response (damn time different!). I had not experienced mavros only sending one vision estimate. I did experience intermittent VISION timeouts on PX4 though when running mavros on Odroid connected with USB to Pixhawk. I believe this was due to overloading the USB bus on Odroid, so I actually implemented the same change as you, slow done the tf_listener rate in vision_position plugin. I set mine to 10hz as any faster is a waste (ar_track_alvar is only updating the vision estimate at 3.3hz). I need to find the bottleneck here and speed that up. I think we definitely need to sync vision_position plugin rate to the same rate as the vision estimate package otherwise we are wasting bandwidth https://github.com/vooon/mavros/issues/60. What rate is your ar_track_alvar producing estimates?

    Regarding parameters for vision see https://github.com/PX4/Firmware/pull/1221. If this hasn't been merged yet just substitue VIS with GPS.

    点赞 评论 复制链接分享
  • weixin_39559750 weixin_39559750 4月前

    Hi ,

    The reason why I had to adjust the rate and you not is simple: I'm running in my laptop with a Haswell i7 and not on the Odroid :) As we need to give an option so people can also run this algorithms offboard, preparing this as a testbench should also be done. In this case, and since this is a research for my MSc, this could be interesting to understand the performance of the Odroid vs a higher performance system.

    Possibly (didn't test it yet) I'll get a similar rate of estimates as you in the Odroid. ar_track_alvar, though, compared with the visual odometry pkgs and SLAM algorithms I have to run, it's fast :D I'll have to find a way of getting a proper visual odometry running on the Odroid, since I'll be also doing mapping with it. One thing I found is that the USB bus gets overloaded when connecting, for example, a Asus Xtion, a dual-band wifi dongle and the serial cable to Pixhawk. Unfortunately, that's the setup I need. I'll have to adjust the rates so I can have the system properly working. Don't know if a power hub can help, but that's an option I don't want to consider for now (more weight, more power consumption).

    Anyway, I'm also waiting for the px4flow cable so I can add it to the system. As the visual odometry systems function at low rates, using a higher rate pose estimation from flow will help stabilize the quad during it's motion.

    ---Nuno MarquesAlferes Aluno de TransmissõesAluno de Mestrado em Engenharia Electrotécnica e de ComputadoresInstituto Superior Técnico | Universidade de Lisboa +351 912 090 991Azambuja | Portugal Dreams set what you want. Actions determine what you conquer!This message and any files herewith attached may contain confidential or privileged information and is intended solely for the use of the entity to which it is addressed. If you receive this message in error, please notify the sender immediately and delete this message and any files attached without copying them in any way.

    Date: Tue, 22 Jul 2014 19:18:21 -0700 From: notifications.com To: Firmware.github.com CC: n.marques21.com Subject: Re: [Firmware] Vision estimate (#1041)

    Sorry for delayed response (damn time different!).

    I had not experienced mavros only sending one vision estimate. I did experience intermittent VISION timeouts on PX4 though when running mavros on Odroid connected with USB to Pixhawk. I believe this was due to overloading the USB bus on Odroid, so I actually implemented the same change as you, slow done the tf_listener rate in vision_position plugin. I set mine to 10hz as any faster is a waste (ar_track_alvar is only updating the vision estimate at 3.3hz). I need to find the bottleneck here and speed that up. I think we definitely need to sync vision_position plugin rate to the same rate as the vision estimate package otherwise we are wasting bandwidth vooon/mavros#60. What rate is your ar_track_alvar producing estimates?

    Regarding parameters for vision see #1221. If this hasn't been merged yet just substitue VIS with GPS.

    — Reply to this email directly or view it on GitHub.

    点赞 评论 复制链接分享
  • weixin_39559750 weixin_39559750 4月前

    is it possible to add vision attitude estimation also? I'm asking this cause in indoor environments, orientation of the MAV must be sync with the estimated orientation of the camera, right? That is to be able to do a position + orientation control.

    点赞 评论 复制链接分享
  • weixin_39606137 weixin_39606137 4月前

    PX4Flow doens't work properly now. I'm not sure if this is after Glenn's PR or not. Might check against master / previous commit to check.

    Basically, flow data is fine, but Local_X and Local_Y don't change properly. A strong wiggle makes it move a bit, but this is because of the IMU integration I think. The flow position estimate doesn't work at all.

    This might affect GPS too, but I haven't tested.

    点赞 评论 复制链接分享
  • weixin_39559750 weixin_39559750 4月前

    An update: It seems like that the firmware receives the vision estimate and the local position just receives that estimate once and stays locked in that x/y (with only z changing according to weight that is given to baro vs GPS/vision).

    For example, if I kill mavros and run it again, it sends a new vision estimation and checking on rviz it seems it keeps stuck on that x/y estimation, even though I change the camera position. I'm trying this with ar_track_alvar pkg.

    So a tip on this: vision position is just sent once or is just received once - the first one. Then it locks the x/y position in the firstly received vision estimate.

    Still, position lock keeps activated (green led slowly blinking), even though no valid vision estimate is being sent, as referred before.

    点赞 评论 复制链接分享
  • weixin_39926749 weixin_39926749 4月前

    I have submitted a PR https://github.com/PX4/Firmware/pull/1221 which separates the position correction for vision estimate logic out from the GPS logic. This also fixes the LED indication for valid position.

    点赞 评论 复制链接分享
  • weixin_39606137 weixin_39606137 4月前

    Great thanks for the patches :)

    On Tue, Jul 22, 2014 at 6:39 PM, ggregory8 notifications.com wrote:

    https://github.com/LorenzMeier I have submitted a PR which separates the position correction for vision estimate logic out from the GPS logic. This also fixes the LED indication for valid position.

    — Reply to this email directly or view it on GitHub https://github.com/PX4/Firmware/pull/1041#issuecomment-49736076.

    点赞 评论 复制链接分享
  • weixin_39559750 weixin_39559750 4月前

    Thanks . Let's check it's behaviour after the patch ;)

    点赞 评论 复制链接分享
  • weixin_39559750 weixin_39559750 4月前

    By the way, what's your opinion on the last behaviour I referred? Does it also happen to you guys? (local position being stuck on the first vision estimate?)

    点赞 评论 复制链接分享
  • weixin_39926749 weixin_39926749 4月前

    The functionality should be exactly the same as before except for the LED should now change color if there is no position lock i.e VISION timeout.

    I am not seeing that behaviour. I suggest adding the a printf in the vision_position plugin as I mentioned a few posts back to see the exact xyz it is sending. Are you getting the timeout in QGC?

    How has your testing been going of vision_estimate? Are you able to fly?

    点赞 评论 复制链接分享
  • weixin_39606137 weixin_39606137 4月前

    I'm just waiting for some hardware before I can fly :) On Jul 22, 2014 6:50 PM, "ggregory8" notifications.com wrote:

    The functionality should be exactly the same as before except for the LED should now change color if there is no position lock i.e VISION timeout.

    https://github.com/TSC21 I am not seeing that behaviour. I suggest adding the a printf in the vision_position plugin as I mentioned a few posts back to see the exact xyz it is sending. Are you getting the timeout in QGC?

    https://github.com/mhkabir How has your testing been going of vision_estimate? Are you able to fly?

    — Reply to this email directly or view it on GitHub https://github.com/PX4/Firmware/pull/1041#issuecomment-49737292.

    点赞 评论 复制链接分享
  • weixin_39559750 weixin_39559750 4月前

    would you mind share your parameter.txt so I can load it to the Pixhawk? The vision estimate values seem good but the local position doesn't seem to update with each one being sent :S

    点赞 评论 复制链接分享
  • weixin_39812577 weixin_39812577 4月前

    Are you using mavros or a different type of bridge? could you check if the vision updates are sent regularly? It sounds like they're sent only once.

    点赞 评论 复制链接分享
  • weixin_39559750 weixin_39559750 4月前

    same problem here.

    点赞 评论 复制链接分享
  • weixin_39559750 weixin_39559750 4月前

    I installed mavros with the last updates (which includes the libdev thing). It doesn't stay connected!! After a couple of seconds I get:

    [ WARN] [1406041931.258771857]: CON: Lost connection, HEARTBEAT timed out.

    I receive local_position and send vision_estimate only once. Then it breaks. The other data streams also crash (like /imu/data).

    can you please check what's happening?

    Anyone facing the same troubles?

    Update: I was using the 3DR radio kit to establish connection but changed to direct usb connection and got the same results. So the bridge is not working right in my case.

    点赞 评论 复制链接分享
  • weixin_39553653 weixin_39553653 4月前

    Please add notes what port do you use. In my tests libev works very well. Because it works at start i think something goes wrong in Firmware (no HB, no IMU messages). You can check it: simply connect terminal on that port (it stops mavros) and see what px sends. Usually it looks like garbage with some text strings (STATUSTEXT).

    点赞 评论 复制链接分享
  • weixin_39559750 weixin_39559750 4月前

    ports: /ttyACM0 when USB connected to Pixhawk; /ttyUSB0 when connected through 3DR radio. How can I do that? Using putty for example?

    Update: Already tried to listen to port using putty. When I connect, mavros goes down but the log that appears is almost impossible to read (with strange chars) and always updating.

    点赞 评论 复制链接分享
  • weixin_39553653 weixin_39553653 4月前

    I think easier minicom -D <dev> -b <baud> (req. configuration at first time) or miniterm.py from python-serial.

    点赞 评论 复制链接分享
  • weixin_39559750 weixin_39559750 4月前

    Still impossible to read! But I found a tip that may help: It goes down immediately when it enters position lock. Meaning that when it (the PX4) receives the first vision_estimate, the connection is lost. Till then it works ok!

    点赞 评论 复制链接分享
  • weixin_39926749 weixin_39926749 4月前

    As I mentioned on px4users mailing list when I view the local_position_ned.x in QGC the value drifts exponentially when I send it a constant vision_position_estimate.

    I think I found the problem that it is running the inertial_filter_predict() but not the inertial_filter_correct() due to the if (use_gps_xy) condition. I changed line 784 to bool use_gps_xy = (ref_inited && gps_valid && params.w_xy_gps_p > MIN_VALID_W) || vision_valid; and it seems to be working now.

    What is the best way to debug the PX4 firmware. Can we printf to the NSH console? I found if I stopped an app in NSH and then started it again without backgrounding it I can get warnx messages. Is this the best way?

    点赞 评论 复制链接分享
  • weixin_39812577 weixin_39812577 4月前

    This is something for you 8)

    点赞 评论 复制链接分享
  • weixin_39812577 weixin_39812577 4月前

    The warnx() message go to the current console, which is by default on SERIAL4/5 (pin 4 (TX), pin 5 (RX), pin 6 (GND)). See the PX4 wiki (search for wiring) for details. If you stop the app via USB console and restart it, it will send its output to the USB console. That's a viable option if you don't mind the restart. We mostly use an FTDI on the serial console to also be able to watch the boot log.

    点赞 评论 复制链接分享
  • weixin_39812577 weixin_39812577 4月前

    Can you send a pull request for your change?

    https://help.github.com/articles/using-pull-requests

    点赞 评论 复制链接分享
  • weixin_39926749 weixin_39926749 4月前

    I can't use Serial5 because the pins 4&5 are broken, I was hoping to switch the default console to Serial4 until I get a new connector. I guess the stop/start option will do until then, also the mavlink_log_info() function, while not ideal, works for debugging :)

    I will do the PR but unfortunately I have no time at the moment. I won't be able to get back to this for a few days. If it is still outstanding by then I will do it.

    Thanks

    点赞 评论 复制链接分享
  • weixin_39926749 weixin_39926749 4月前

    I have finally made my first pull request: https://github.com/PX4/Firmware/pull/1065

    点赞 评论 复制链接分享
  • weixin_39812577 weixin_39812577 4月前

    Could you please review the INAV changes? Its ok if they are hacky on the vision side, but I want to be sure we don't ruin the GPS-only performance with these changes.

    点赞 评论 复制链接分享
  • weixin_39812577 weixin_39812577 4月前

    Could you please provide some additional guidance / feedback / patches here? I would like to move forward with the integration and a lot of people would be unblocked by this.

    点赞 评论 复制链接分享
  • weixin_39613824 weixin_39613824 4月前

    , I think first need to fix issues that I found: add corr_vision and use is separately instead of using corr_gps. Unfortunately, I have no time for this now, maybe later. , can you do this?

    点赞 评论 复制链接分享
  • weixin_39812577 weixin_39812577 4月前

    Is this something you could pick up? The goal would be to accept vision estimates as soon as possible in the master branch so you can code ahead in ROS. I'm aware that you plan to to all estimation within ROS, however, doing the estimation in the autopilot does have the benefit of a) continue to work (given GPS) if the Linux computer (during testing) fails, b) it will immediately work and give you faster results,

    and most importantly c) has high-rate IMU feedback which will make it much more robust and less laggy (as there is no communication latency of the sensors involved).

    点赞 评论 复制链接分享
  • weixin_39729840 weixin_39729840 4月前

    Hi, I wrote a plugin which sends a message to the VISION_POSITION_ESTIMATE using this functions:

    mavlink_msg_vision_position_estimate_pack(0, 0, &msg,usec,x,y,z,0,0,0); uas->mav_link->send_message(&msg);

    what I noticed is the follwing, the LOCAL_POSITION_NED follows the x and y data I sent exactly. However, the z value of the LOCAL_POSITION_NED doesn't change or follow what ever I sent. It only changes when the IMU data change (the pix4/Quadrotor moves).

    点赞 评论 复制链接分享
  • weixin_39926749 weixin_39926749 4月前

    I can look into doing this if it is still outstanding in a weeks time. I have been extremely busy so haven't had time to spend on this like I wanted to and I have a few weeks off work so will have heaps of time :)

    点赞 评论 复制链接分享
  • weixin_39926749 weixin_39926749 4月前

    What issues are you facing exactly with using the vision_estimate branch with mavros so I can have a look at these? I know of: - Separate vision corrections from GPS corrections (doesn't actually create a problem for our vision only testing) - When vision estimate stops the Z estimate in PX4 increments to infinity - When vision estimate is regained, it sometimes does not bring the location position back to vision estimate (potentially due to the local estimates being so far off)

    点赞 评论 复制链接分享
  • weixin_39559750 weixin_39559750 4月前

    for now I confirm only those and another: position lock doesn't go off if the vision estimation is not received. Also, we will probably have to tweak better the weights of the sensors in the estimator so to have a better pose estimation. When I receive my px4flow cable I'll be doing also some POSCTL with it + the vision estimation.

    点赞 评论 复制链接分享
  • weixin_39606137 weixin_39606137 4月前

    Loss of vision estimate is not detected after merging the last master. Previously, a vision timeout message was sent, but now it doesn't detect loss of estimate. It continues to think that there is a valid position even if mavlink messages are cut off after sending only initially.

    点赞 评论 复制链接分享
  • weixin_39926749 weixin_39926749 4月前

    Thanks guys. I have updated to the lastest vision_estimate branch.

    the timeout is still working for me. If I block the camera I have to wait for mavros to stop sending messages (normally about 5s, we will need to change this in the vision_position plugin) then I get a timeout message in PX4 (500ms after the last recieved vision estimate). So there is quite a delay all up.

    Is mavros definitely not sending a vision estimate? I added a printf here to confirm.

    点赞 评论 复制链接分享

相关推荐