-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PX4 Compatibility #76
Comments
Good question :) No idea, I've never used px4, but it's on my todo list to try. Will keep this open as a reminder. |
PX4 still doesn't support |
@TSC21 Are you working on coding support for LANDING_TARGET in px4 firmware? Are you planning on doing something more complex than sending camera frame angles (mavlink/mavlink#744)? |
Yes I am. Coding it right now according to mavlink/mavlink#744. Till it is merged and applied on |
Why do you need to extend landing_target? Can you not code px4 to use camera frame radians, like arducopter? |
I could but it is much more intuitive to use full pose of the target instead (it may happen that the landing target isn't even in a flat surface, for example). |
Sounds interesting, I agree it's much nicer to use the pose if it's available. Bonus points if you can support a gimbal :) |
That can also be considered. In ROS you can listen to transforms, and knowing the current camera pose, you can compute the transform from the target (which will be in a certain frame - better to consider NED frame as we already do the transforms from ENU to NED), to the camera center. That way you don't really need to have the camera always pointing down, and you can basically have it tracking the the landing target. But you will need a mechanism that gives you feedback of the current gimbal position (I suppose that if you have a SToRM32, you can have a way of getting the gimbal orientation and fed it to the position controller, or even to ROS, if you had some kind of msg that could send that info). |
Even if the flight controller only controls the gimbal through PWM, it should be able to use the intended position instead of actual position through feedback from the gimbal/imu? |
Well that's how controllers and actuators work I suppose: you know the orientation you want to give to the camera (for example, you wanna fix the position of the target so you can fix the gimbal on it), so you use the controller to compute the desired orientation to it. http://ardupilot.org/copter/docs/common-storm32-gimbal.html here you have a way of knowing what values to send based on the max angles and rates. Knowing the gimbal orientation, you know the camera orientation. |
I'm picking the SToRM32 cause it is Mavlink-based and with neat features. |
@TSC21 wow, great that you are working on it. I am happy to do testing :) |
@TSC21 did you get further with this? I could not exactly figure out what the state of it is in the px4 source. |
Still working on it |
I am a bit confused on where this would actually be implemented. Will this be part of the core px4 firmware? I saw MAVROS sugested here http://discuss.px4.io/t/visual-precision-landing/2418/9 |
That can be an approach also. But to be available, it will be on the firmware side. MAVROS serves as a bridge, not as an app, so you have to write your own node to do that. Still ROS would be useful to retrieve and process marker tracking, while the landing process can be implemented om both sides. |
@TSC21 thanks for the explanation. Can you give me a hint on where you implement the feature in the px4 source? Is that a public repository or will you only publish it when it's "finished"? |
I'm going for the ros implementation for now as it is quicker. For the px4 implementation could take some more time as the |
@TSC21 how is the ROS implementation coming along? :) |
@TSC21 Can you give me a hint on where to look/start? Will this be in the mavros repo? https://github.com/mavlink/mavros/commits?author=TSC21 |
@TSC21 Any pointer on where to look would be great. I can't find the related code anywhere. Or are you currently doing the development in private? |
@TSC21 Good to see some progress. It's not entirely clear from that PR conversation if they have gone the generic route, or if it's irlock only as per the original PR? |
For now is just the irlock. If Nicolas does not just generalize it, I will do it myself. |
thanks. Indeed very good to see some progress. Hoping for a generic implementation and not the irlock specific. |
@TSC21 Now irlock precland support is in px4, how do we get mavlink (or more likely rtsp) sensor support in? |
I am working on that but I am currently swamped with other matters. |
I wonder if the new VIO stack for PX4 resulted in any improvements that allows more generic precision landing implementations with PX4 now (rather than only irlock). |
@petergerten That would be great, I'm resurrecting this project hopefully with proper support in ardupilot, would be great to support px4 as well. |
It already supports external vision landing yes. But it expects the full pose and not angles. |
Are there any docs or sample code? I couldn't see any at a quick search. |
You did commented on it as well: PX4/PX4-Autopilot#9050 |
I am still very interested in getting it running with PX4 or PX4+ROS - did anyone get closer on this yet? |
@petergerten the implementation is done as you can see above. The only thing is that the landing_target plugin was not merged yet, though it is usable (I am exploring it in 2 different projects currently). The only thing is that the data that you send on thr message needs to be the absolute position of the target on the local frame, since the current implementation in PX4 expects that (which is not completely right). Though I do consider that this issue can be closed, since the solution is already present. |
@TSC21 Not even remotely 'closed' issue - px4 support is unuseable to anyone that isn't 'in the know', at least last time I looked. If you can point to documentation or guide how to use it, then maybe the rest of the world can use it. |
@TSC21 You mentioned "The only thibg is that the data that you send on thr message needs to be the absolute positiom of the target on the local frame" -> how would I do that? @alchemyconsulting I fully agree with your sentiment... |
@alchemyconsulting if you feel is not well documented or not well supported, then this is something to be discussed and adressed in the appropriate PX4 forum or issue topic, not here. Also we do have documentation for it: https://docs.px4.io/en/advanced_features/precland.html. though it specifies the usage of the IR Lock only, a close look up on the link I sent in some comment above will lead you to understand that also external vision landing target estimatiom feeding is also possible. This is though not matter that is on the top of the priorities at the moment for the dev team in PX4 and not something I do have time to explore the development. @petergerten again, if you want this to be something to be explored and answered, this is not the best place to do it. Just bring this to the PX4 forums ;) |
@TSC21 thanks. I will bring in up in the px4 forums. Can you clarify which branch / pull request you are talking about that you are already using but is not merged yet? |
If you read closely what I wrote above, you will see that the PR to bring support for LANDING_TARGET msg is already merged - PX4/PX4-Autopilot#9050. What's not merged is the PR to MAVROS to add the landing_target plugin - mavlink/mavros#311 - , but that's PX4-independent. |
@TSC21 Would it also be possible to use the path planning interface to facilitate a landing in mission mode and just send TRAJECTORY_REPRESENTATION_WAYPOINTS messages similar to the safe landing planner? |
As the system uses MAVLink for communication, I assume it might also work with the PX4 flight stack?
Has anyone tested this?
The text was updated successfully, but these errors were encountered: