Skip to content

Commit

Permalink
added new definition of guided flag field
Browse files Browse the repository at this point in the history
added new definition of guided flag field
  • Loading branch information
kirkscheper committed Jun 9, 2016
1 parent 0a44f55 commit 971a4b7
Showing 1 changed file with 12 additions and 11 deletions.
23 changes: 12 additions & 11 deletions message_definitions/v1.0/messages.xml
Expand Up @@ -2477,19 +2477,20 @@
<message name="GUIDED_SETPOINT_NED" id="40" link="forwarded">
<description>
Set vehicle position or velocity in NED.
Frame can be specified with the bits 0-3 in the flags field:
0x0: LOCAL_NED
0x1: LOCAL_OFFSET_NED
0x2: BODY_NED
0x3: BODY_OFFSET_NED
Bits 4-7 in the flag field can be used to enable velocity control on specifc fields:
bit 4: x as velocity
bit 5: y as velocity
bit 6: z as velocity
bit 7: yaw as rate
Frame can be specified with the bits 0-3
Velocity of position setpoint can be specified with the bits 5-7
Flags field definition:
- bit 0: x,y as offset coordinates
- bit 1: x,y in body coordinates
- bit 2: z as offset coordinates
- bit 3: yaw as offset coordinates
- bit 4: free
- bit 5: x,y as vel
- bit 6: z as vel
- bit 7: yaw as rate
</description>
<field name="ac_id" type="uint8"/>
<field name="flags" type="uint8">bits 0-3: frame, bits 4-7: use as velocity</field>
<field name="flags" type="uint8">bits 0-3: frame, bits 5-7: use as velocity</field>
<field name="x" type="float" unit="m">X position/velocity in NED</field>
<field name="y" type="float" unit="m">Y position/velocity in NED</field>
<field name="z" type="float" unit="m">Z position/velocity in NED (negative altitude)</field>
Expand Down

11 comments on commit 971a4b7

@hooperfly
Copy link
Contributor

@hooperfly hooperfly commented on 971a4b7 Jun 11, 2016

Choose a reason for hiding this comment

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

Updated the FRC to use the new guided field definitions and I see some inconsistent/unexpected behavior in simulation. I made sure I synced the pprzlink libraries, did a make clean and make on paparazzi, recompiled all of the aircraft for simulation. Prior to this update, the simulation worked as expected. Not sure what might be causing the inconsistencies at this point.
screen shot 2016-06-11 at 3 08 54 pm

@hooperfly
Copy link
Contributor

@hooperfly hooperfly commented on 971a4b7 Jun 11, 2016

Choose a reason for hiding this comment

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

@esden I notice it's the Elle0 v1_2 aircraft that seem to be "confused". In comparing the airframe files between Elle0 v1 and Elle0 v1_2 aircraft, they only differ with respect to the AP Target:

    <target name="ap" board="elle0_1.0"></target>

vs.

    <target name="ap" board="elle0_1.2"></target>

@flixr
Copy link
Member

@flixr flixr commented on 971a4b7 Jun 12, 2016

Choose a reason for hiding this comment

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

@hooperfly and what are the inconsistencies or unexpected behaviours you see?

@hooperfly
Copy link
Contributor

Choose a reason for hiding this comment

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

@flixr the four aircraft along the lower part of the screen, (reference screen capture above), display the expected behavior, the two at the top and the orange one to the right are not behaving the same. All aircraft are getting the same PPRZLink messages and three of them deviate from the pattern; as apparent in the screen capture. Prior to this change, all aircraft flew the exact same patterns. Does that help clarify? It's a repeatable anomaly as well. Doing a differential on the airframe files, flight plan files being used by the aircraft, the only difference is the AP target mentioned above.

@flixr
Copy link
Member

@flixr flixr commented on 971a4b7 Jun 12, 2016

Choose a reason for hiding this comment

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

did you clean and rebuild the nps target for all of them?

@hooperfly
Copy link
Contributor

@hooperfly hooperfly commented on 971a4b7 Jun 14, 2016

Choose a reason for hiding this comment

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

@flixr yes. That's one of the first things I do just after a make clean, make of my latest pull. I'm able to get another airframe to display similar issues and it starting to look like it's correlated to aircraft that start their guided mode when stationed at P1 and P3 in my flight plan. I'll keep poking at it to try and understand why starting at one waypoint vs. another should even matter. I didn't see this kind of anomaly prior to the guided bit field updates.

It might be related to yaw, the z-term. Right after sending a yaw command, that's when I start to get "unpredictable" behavior. Either I am not understanding the new bit field modifications or something is broke, possibly both. 😉

@flixr
Copy link
Member

@flixr flixr commented on 971a4b7 Jun 14, 2016

Choose a reason for hiding this comment

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

Should be fixed with paparazzi/paparazzi#1720

@hooperfly
Copy link
Contributor

Choose a reason for hiding this comment

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

Cool. Thanks. I will test and let you know how it goes.

@hooperfly
Copy link
Contributor

Choose a reason for hiding this comment

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

screen shot 2016-06-14 at 3 34 40 pm

@hooperfly
Copy link
Contributor

Choose a reason for hiding this comment

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

Working much better! See above image. Thanks.

@kirkscheper
Copy link
Member Author

@kirkscheper kirkscheper commented on 971a4b7 Jun 14, 2016 via email

Choose a reason for hiding this comment

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

Please sign in to comment.