Hi Everyone,<div><br></div><div>In response to a few of the questions about the coordinates I was using in the Twist, it was actually an oversight on my part, which I realized when I was writing <a href="http://ros.org/wiki/ardrone_driver">the wiki page</a>. The latest commit message in my repo (about two hours after I announced the package) shows this change. See the wiki page for a description of how the coordinates are used. If there are any further changes anyone has for the coordinates used, let's get them settled now. I think keeping things with REP 103, until an aerial robot standard emerges, would be best.</div>

<div><br></div><div>As far as using gstreamer, I have thought about that, but, unfortunately, the Parrot team have modified the H.263 standard slightly into their own proprietary format. I have the spec on the format, which they have made available, so it can be decoded, it's just a matter of time. I'll give gstreamer a go, just to see if it works; that would sure make things easy.</div>

<div><br></div><div>The units are degrees for the forward/backward and left/right tilt. These control the percentage of the maximum tilt (which is currently 30 degrees). Obviously, the more tilt, the faster it goes. I've found that anything more than 25 degrees actually drives the drone to the ground, so I'm thinking of adding a limit, and/or adding a rosparam allowing the change of the max angle.</div>

<div><br></div><div><br></div><div>Nate Roney<br><br><div class="gmail_quote">On Sat, Oct 16, 2010 at 08:24, Jack O'Quin <span dir="ltr"><<a href="mailto:jack.oquin@gmail.com">jack.oquin@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Sat, Oct 16, 2010 at 5:12 AM, Cedric Pradalier<br>
<<a href="mailto:cedric.pradalier@mavt.ethz.ch">cedric.pradalier@mavt.ethz.ch</a>> wrote:<br>
<br>
> Actually, the standard coordinate frame for flying system is with Z down<br>
> (it allows standard compass angle to be coherent with the X,Y motion).<br>
> For this reason,<br>
> I'm voting in favour of a Z down coordinate system for the AR-Drone.<br>
><br>
> However, I agree that I would be suprised without  x forward, y<br>
> sideways, and yaw around z....<br>
><br>
> As soon as we have velocity control on the CoaX helicopter, our control<br>
> will definitely be like that.<br>
<br>
</div>I realize that the standard aerospace orientation is "upside-down"<br>
compared to the standard robotics orientation as defined in REP 103.<br>
<br>
  <a href="http://www.ros.org/reps/rep-0103.html#axis-orientation" target="_blank">http://www.ros.org/reps/rep-0103.html#axis-orientation</a><br>
<br>
Since the intent of the ROS community is to share code, ignoring REP<br>
103 is a mistake. Your vehicle would display upside-down in rviz, for<br>
example.<br>
<br>
But, note that there is already a documented exception for use with<br>
camera frames (and an "_optical" suffix). If it is really so important<br>
to use the aerospace convention, you should propose a similar<br>
modification to REP 103 and get approval from the whole community.<br>
Maybe an "_aerial" suffix would be appropriate.<br>
<br>
To me, that seems clumsy and unnecessary. You could use standard ROS<br>
frame transform conventions yet still communicate with humans using<br>
idiosyncratic aerospace terminology.<br>
--<br>
<font color="#888888"> joq<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
</div></div></blockquote></div><br></div>