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

[Nate Roney]

Thanks for the feedback.

Initially, I set out to use a Twist for the purpose of making things easy to
use. And it made perfect sense initially, as I needed to control linear and
angular motion. I still think it's the best thing to use for control, albeit
in a non-standard way (for now), so long as it is documented to work in this
way. I agree with your point that more meaningful units would be nice,
though at this early stage. I think I'll be best served working toward
converting things internally, rather than adding another layer to the
control. That way, the Twist could be expressed in m/s and rad/s.

One of the main limitations with the AR.Drone is the lack of documentation
on low level commands. Further, the onboard controller is entirely
closed-source, so getting at things like IMU data, and other things like how
the drone actually acts upon the movement commands sent to it, is proving
quite challenging. Ultimately, the reason for getting the word out about
this driver early was to get feedback from the community on how things
should work, which I certainly am :). I'm glad to listen, and will most
definitely work in suggestions from everyone to the future releases of this.

The docs on the wiki and the repository will of course be updated
accordingly if and when any changes are made.

Nate Roney

On Sat, Oct 16, 2010 at 12:11, Eric Perko <wisesage5001 at gmail.com> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/361a8137/attachment-0003.html>