Skip to content
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

Copter: support MAV_FRAME_LOCAL_NED in MISSION_ITEM for auto mode #16259

Closed

Conversation

amilcarlucas
Copy link
Contributor

@amilcarlucas amilcarlucas commented Jan 7, 2021

This is based on #8748 and #15854

Here is the original description from @chobitsfan :

For indoor flight with external navigation data (ATT_POS_MOCAP or VISION_POSITION_ESTIMATE), it is not possible to flight auto mission with latitude/longitude waypoint.

This PR allows mission waypoint be assigned in MAV_FRAME_LOCAL_NED coordinate system. To do this, GCS can send mission_item message with frame = MAV_FRAME_LOCAL_NED (1).

Currently only takeoff and waypoint support local_ned frame

Test flight video, this mission contains 4 command: takeoff, waypoint 1 (local coordinate 1.2, 1.2) , waypoint 2 (local coordinate 1.2,-1.2) and land
2 waypoints are marked in red cross on the floor
I use mavproxy wp load for uploading mission to copter
https://youtu.be/gVgK41gS7Hc

And some more testing was done by @roackb2 :

Here's the video
This is the flight plan
And this is the parameters I use
Hardware: Pixhawk 2.4
Vision: Intel Realsense T265
Companion Computer: Raspberry Pi 3B+
script running on companion computer to feed position data to flight control is here

@amilcarlucas
Copy link
Contributor Author

All CI tests pass now :)

@@ -586,6 +586,7 @@ struct PACKED Packed_Location_Option_Flags {
uint8_t terrain_alt : 1; // this altitude is above terrain
uint8_t origin_alt : 1; // this altitude is above ekf origin
uint8_t loiter_xtrack : 1; // 0 to crosstrack from center of waypoint, 1 to crosstrack from tangent exit location
uint8_t local_frame : 1; // 1 if lat/lng is N/E postion vector in centimeters relative to ekf origin
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this changes the binary format of our mission storage. I am concerned that this could break existing missions in storage on stm32 or linux boards to re-interpret

@rmackay9
Copy link
Contributor

We discussed this at length on the dev call but had these concerns:

  • the changes to the eeprom format for missions means we need careful testing on various boards to ensure following bits aren't affected
  • relative yaw is not handled
  • although it is huge scope creep ideally we would move the mission storage to a variable size format instead of the fixed format we use now. This would allow more waypoints (not that anyone is complaining) but perhaps also allow more flexibility in changing the size and/or format.

@amilcarlucas
Copy link
Contributor Author

@chobitsfan can you follow up on this one? This is out-of-my-league

@chobitsfan
Copy link
Contributor

Hi @amilcarlucas Yes. I will try to do it

@chobitsfan
Copy link
Contributor

Hi @amilcarlucas I created #16627. try to fix the problem raised by @tridge in #16259 (comment)

@amilcarlucas
Copy link
Contributor Author

@chobitsfan Thanks for the follow up

@amilcarlucas amilcarlucas deleted the pr_mission_local_frame2 branch February 15, 2021 13:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants