Nate, On Sat, Oct 16, 2010 at 10:02 AM, Nate Roney 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 . 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 wrote: > >> On Sat, Oct 16, 2010 at 5:12 AM, Cedric Pradalier >> 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@code.ros.org >> https://code.ros.org/mailman/listinfo/ros-users >> > > > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users > >