[ros-users] ROS Interface for AR.Drone Quadrotor

Eric Perko wisesage5001 at gmail.com
Sat Oct 16 17:11:15 UTC 2010


Nate,

On Sat, Oct 16, 2010 at 10:02 AM, Nate Roney <nateroney at gmail.com> wrote:

> Hi Everyone,
>
> 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 the wiki page <http://ros.org/wiki/ardrone_driver>. 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.
>

Thanks for updating the docs. I also agree with keeping to REP 103 until
some other standard is fleshed out is a good idea.


>
> 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.
>

> 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.
>

A limit with a rosparam would be very nice :). I'd not want to accidentally
drive a quadrotor into the ground.

One thing that is a bit odd (at least in my experience) is Twist being
expressed in terms of percentages. Any other time I've seen Twist used, it's
always in units of velocity (distance/time), and generally m/s for the
linear components and rads/s for the angular components. Percentage of
maximum tilt might be best in a joystick type message or something similar.
That would leave cmd_vel and Twist (as real velocities) available for some
future node that implemented a controller that took in m/s and rad/s and
modulated the existing tilts in order to generate the desired motion. One
thing to think about is that we ought to be able to get a distance (whether
linear or an arc length in rads) by integrating a velocity over time -
definitely cannot do that with percentage of max effort :)

Hopefully we can make sure that the interface is pretty standard before
people start using it and then it becomes painful to change :)

- Eric


>
>
> Nate Roney
>
>
> On Sat, Oct 16, 2010 at 08:24, Jack O'Quin <jack.oquin at gmail.com> wrote:
>
>> On Sat, Oct 16, 2010 at 5:12 AM, Cedric Pradalier
>> <cedric.pradalier at mavt.ethz.ch> wrote:
>>
>> > Actually, the standard coordinate frame for flying system is with Z down
>> > (it allows standard compass angle to be coherent with the X,Y motion).
>> > For this reason,
>> > I'm voting in favour of a Z down coordinate system for the AR-Drone.
>> >
>> > However, I agree that I would be suprised without  x forward, y
>> > sideways, and yaw around z....
>> >
>> > As soon as we have velocity control on the CoaX helicopter, our control
>> > will definitely be like that.
>>
>> I realize that the standard aerospace orientation is "upside-down"
>> compared to the standard robotics orientation as defined in REP 103.
>>
>>  http://www.ros.org/reps/rep-0103.html#axis-orientation
>>
>> Since the intent of the ROS community is to share code, ignoring REP
>> 103 is a mistake. Your vehicle would display upside-down in rviz, for
>> example.
>>
>> But, note that there is already a documented exception for use with
>> camera frames (and an "_optical" suffix). If it is really so important
>> to use the aerospace convention, you should propose a similar
>> modification to REP 103 and get approval from the whole community.
>> Maybe an "_aerial" suffix would be appropriate.
>>
>> To me, that seems clumsy and unnecessary. You could use standard ROS
>> frame transform conventions yet still communicate with humans using
>> idiosyncratic aerospace terminology.
>> --
>>  joq
>> _______________________________________________
>> ros-users mailing list
>> ros-users at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>>
>
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20101016/5764d33a/attachment-0003.html>


More information about the ros-users mailing list