Closed mhkabir closed 9 years ago
If you do the math of the 8 bytes per message overhead you'll notice quickly that it doesn't really matter. Plus you can easily go to 460800 baud link speed (which you anyway should to reduce latency). Feel free to propose a message and we can look into it, but since they are on different levels (raw data vs. attitude estimate) I'm not sure they have to be in the same frame. Sending them together also would create the false illusion that they are off the same time - the attitude estimate is always with some slight delay compared to the raw data.
Okay then.
I'm running the link at 921600, might this have any unforseen adverse effects? While 460800 should be more than enough, running at 921600 should give the highest throughput with lowest latency, correct?
A problem I faced is that while running ATTITUDE and HIGHRES_IMU at 200Hz each, my PC cannot stay connected to the Pixhawk connected via USB and keeps getting and dropping the link. This would point to a USB bandwidth limitation, but this makes no sense as the Odroid pulls through just fine. When I connect through the Odroid and pipe the data through UDP using mavros (same rate), connection works absolutely fine.
On Tue, Aug 12, 2014 at 4:49 PM, Lorenz Meier notifications@github.com wrote:
If you do the math of the 8 bytes per message overhead you'll notice quickly that it doesn't really matter. Plus you can easily go to 460800 baud link speed (which you anyway should to reduce latency). Feel free to propose a message and we can look into it, but since they are on different levels (raw data vs. attitude estimate) I'm not sure they have to be in the same frame. Sending them together also would create the false illusion that they are off the same time - the attitude estimate is always with some slight delay compared to the raw data.
— Reply to this email directly or view it on GitHub https://github.com/PX4/Firmware/issues/1269#issuecomment-51901423.
After further checking, and on updating to latest vision_estimate branch, with a modified rc.usb to stream the IMU messages at 150Hz, I just found that whatever rates I request, I'm getting exactly half of that on all messages (i.e 150 -> ~74 Hz)
This looks like a bug in master, so I'll look into this.
Here is my USB startup script:
mavlink start -b 921600 -d /dev/ttyACM0 -m custom -x
mavlink stream -d /dev/ttyACM0 -s PARAM_VALUE -r 200
usleep 100000
mavlink stream -d /dev/ttyACM0 -s NAMED_VALUE_FLOAT -r 10
usleep 100000
mavlink stream -d /dev/ttyACM0 -s OPTICAL_FLOW -r 50
usleep 100000
mavlink stream -d /dev/ttyACM0 -s ATTITUDE -r 150
usleep 100000
mavlink stream -d /dev/ttyACM0 -s HIGHRES_IMU -r 150
usleep 100000
mavlink stream -d /dev/ttyACM0 -s LOCAL_POSITION_NED -r 10
usleep 100000
@LorenzMeier Does is seem to be OK?
I am also trying to steam both HIGHRES_IMU and ATTITUDE at 200Hz via Serial port to a PC recently. However it seems I can only get about 150Hz each. And the mavlink app consumes more than 20% of CPU. Any suggestion to increase the rate while decrease the CPU time?
@LorenzMeier I want to look into this now. I'll email you the message proposal. This would be important for camera trigger functionality too. The ROS IMU message spec is :
geometry_msgs/Quaternion orientation
float64[9] orientation_covariance
geometry_msgs/Vector3 angular_velocity
float64[9] angular_velocity_covariance
geometry_msgs/Vector3 linear_acceleration
float64[9] linear_acceleration_covariance
So we'd want a message which would fill this in one go. Grab the data from uORB topic vehicle_attitude. Also, we should make this message something like SYNCHRONISED_IMU with a 2 time fields, one with boot time and one synced to companion time (use this for camera trigger sync)
Kabir
Cool. Have you looked at http://mavlink.org/messages/common ? There are a bunch of options.
Indeed. As such, I don't think we need to make a new message.
I checked it out and we can simply extend the ATTITUDE message to include linear acceleration.
Would this be alright? On 25 Dec 2014 20:10, "Lorenz Meier" notifications@github.com wrote:
Cool. Have you looked at http://mavlink.org/messages/common ? There are a bunch of options.
— Reply to this email directly or view it on GitHub https://github.com/PX4/Firmware/issues/1269#issuecomment-68104980.
Hi there guys!
I am currently building up a ROS-based rover using the PX4, so I found this posting doing some research. I managed to get the mavros bridge working and I am able to see the HIGHRES_IMU data for example. One of my questions was already answered by Lorenz, it was about the difference between ATTITUDE and HIGHRES_IMU, since we want the same as mhkabir, orientation AND IMU data in one message. My oder question is in general about the correspondencies between the mavlink streams , eg "HIGHRES_IMU" and the resulting published rostopics. Is there any documentation available which data is streamed in Mavlink under what data stream, and under which topic this will be published under ROS using mavros? The official docu of MAVLINK (https://pixhawk.ethz.ch/mavlink/) is not very helpful to me at this place and I hope you can help me =)
best regards Marcel
I just found this one which covers nearly all of my questions : http://wiki.ros.org/mavros#Utility_commands
Thanks a lot guys, writing all this stuff down helped a lot :D
@mstuettgen @mhkabir hi guys, I just got a Qualcomm Snapdragon Flight and installed px4 Firmware onto it. May I know how you those IMU message ot HIGHRES_IMU data? as in which rosnode or roslaunch file I need to run to get those topics?
Thanks a lot
In the present implementation with the ROS bridge, we need to stream 2 types of mavlink messages (ATTITUDE and HIGHRES_IMU) for the full complement of IMU data (linear acceleration, angular velocity and orientation computed by AHRS)
Now, if we are streaming offboard at high rates (say for example 100hz) , it would be better to stream a single message at 100Hz rather than 2 separate messages at 100Hz each. This could be implemented as a option, not activated by default.
I can do this, if we have a standard message for all the data in one go. @LorenzMeier What do you think?
Kabir