search

Ozgenur / happykillmore-gcs

Automatically exported from code.google.com/p/happykillmore-gcs
Other
0 stars 0 forks source link

output of MAVLINK "RC_CHANNELS_RAW" message format error #35

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
- What steps will reproduce the problem?
1. Configure and enable a joystick to output "ardupilot mega" data.
2. Select the "serial data" tab. Optionally, connect the GCS to a virtual 
serial port and grab the data output from the GCS.
3. Move the joystick's controls and observe the data output in the serial 
monitor or serial port sniffer.

- What is the expected output? What do you see instead?
The expected output (as far as I understand) is a serial stream of a 
RC_CHANNELS_RAW mavlink message. This stream should be composed by a start sign 
(0x55), a Payload length (0x12), Packet sequence, System ID, Component ID 
(those 3 values are irrelevant at the moment), the comes the Message ID (that 
should be 0x23).
What it is in the real output is a Message ID of 0x46. But, curiously, in a 
previous release of this GCS this message was formatted well (with a message ID 
of 0x23).
Another fact is that in a previous release of GCS the message ID was correct, 
and the payload length was assigned a value of 0x11 (17 bytes), and in the 
current release this value has changed to 0x12 (18 bytes). I think the correct 
value should be 0x11 (17 bytes), as the payload for this message is composed by 
8 16bit-values plus 1 8bit-value.

- What version of the product are you using? On what operating system?
The problem is in version lite-1.3.16

- Please provide any additional information below.

Original issue reported on code.google.com by robertop...@gmail.com on 15 Jul 2011 at 12:00

GoogleCodeExporter commented 8 years ago 
Everything you said above is true. Originally, Tridge had selected 
RC_CHANNELS_RAW (#35) to be used for joystick output. This MAVlink message was 
designed to be sent from the plane to the GCS not the other way around as there 
is no "target" vehicle specification in that message. So instead, we are now 
using a message that apparently has not been added to the online MAVlink 
specification (not sure why as we did get the OK from Lorenz).

It is message ID #70d and includes a target vehicle ID byte, a target component 
(defaults to 1) and then the 8 channels. RSSI is not included on this message. 
This makes the payload one character larger than the #35 message. Sorry for the 
confustion. What project are you working on where you've had to figure out this 
level of detail? If you want, I can add another selection in the drop-down to 
output the original #35 message if you have a product you're going to sell or 
do something open-source. If you have the ability to change to message #70 I 
would recommend you do so as #35 doesn't work in a multi-vehicle environment 
(or with APM or ACM anymore).
http://pixhawk.ethz.ch/wiki/mavlink/

Original comment by paulbmather@gmail.com on 15 Jul 2011 at 12:16

GoogleCodeExporter commented 8 years ago 
Hi! I appreciate very much your fast answer and also your kind offer to 
implement an option for message 35 in the GCS!

As you said, the message 70 seems not to be implemented in the Mavlink 
definition, and now I understand why I didn't found any information on the web 
about this 0x46 message I was looking at, hence my conclusion was "It is a bug 
in GCS software". I apologize for that mistake! :-D

Following your suggestion, I'll switch to message 70 in my Arducopter software, 
and then I'll let you know how this is working.

I'm tutoring a student who is assembling an Arducopter2 quadrotor, and we 
wanted to control the MAV completely through the HK GCS (which is awesome piece 
of software, by the way!) using Xbee as the wireless link. I had to study a big 
part of the Arducopter2 code to understand how to do this full GCS 
teleoperation, and this study includes the Mavlink protocol and libraries, and 
how to develop new (or not-yet implemented) message sending and receiving. When 
things start not to work as expected, you have to go through all the system 
levels checking everything out, and lastly at the byte streaming level was the 
place where I found a reason of the inability of my system to receive joystick 
data. 

Thank you, again!
Best regards,
Roberto.

Original comment by robertop...@gmail.com on 15 Jul 2011 at 2:02

GoogleCodeExporter commented 8 years ago 
No problem. One thing to keep in mind is the X-Bee is a half duplex device. So 
if your baud rate is too slow, the telemetry stream may "swamp" the outbound 
joystick messages. Which model X-Bee's are you using? I recommend either the 
X-Bee Pro 900's or the 9Xtend modems. They are both capable of 57600+ baud and 
will do just fine with the higher speed 2-way communications of MAVlink. The 
joystick outbound max rate is 20Hz when moving the sticks. When you're not 
moving the sticks, I think it sends at 1Hz as a "heartbeat" so the APM doesn't 
set control back to the R/C radio...

Let me know how things go!

Original comment by paulbmather@gmail.com on 15 Jul 2011 at 2:26

GoogleCodeExporter commented 8 years ago 
Well, I've just finished the deployment of the code to receive the message 
#70d. The HK GCS and my version of the Arducopter2 code communicates through 
XbeePro900 perfectly!!! 
Right now I have with me just the electronics of the MAV. Tomorrow I'll install 
everything in the MAV frame with my student and try to fly.
I'll inform you any news...

Original comment by robertop...@gmail.com on 16 Jul 2011 at 7:12

GoogleCodeExporter commented 8 years ago 
Video or screenshots please!!!!

Original comment by paulbmather@gmail.com on 25 Jul 2011 at 2:27

GoogleCodeExporter commented 8 years ago 
Hello! I am doing the same project by using XBee to control the quadcopter. 
Can u share the source code with me?

Original comment by zhwe...@gmail.com on 27 Sep 2011 at 1:07

GoogleCodeExporter commented 8 years ago 
Hello! I am doing the same project by using XBee to control the quadcopter. 
Can u share the source code with me?

Original comment by zhwe...@gmail.com on 27 Sep 2011 at 1:07

GoogleCodeExporter commented 8 years ago 
Hi! ...I'm sorry for the delay in the answers...
I'll send you this Sunday the source files of my Arducopter version.
Paulbmather, I still have to upload the videos of the machine flying; I'll do 
that as soon as my student gives them to me... he finished his degree and has 
disappear since then!

Original comment by robertop...@gmail.com on 30 Sep 2011 at 7:40

GoogleCodeExporter commented 8 years ago 
I'm new to code.google...
How to check that whether I had received the source file??

Original comment by zhwe...@gmail.com on 4 Oct 2011 at 4:36

GoogleCodeExporter commented 8 years ago 
Source code can be found here: 
http://code.google.com/p/happykillmore-gcs/source/checkout

Original comment by paulbmather@gmail.com on 4 Oct 2011 at 4:42

GoogleCodeExporter commented 8 years ago 
Hi,
Here I attach the modified ArducopterMega 2.0.35 code which understands the new 
#70 message from GCS. 

In general, these are the steps followed to modify the code:
    - Exchange serial and serial3 ports assignations.
    - Implement new mavlink message decodification
    - Assign the mavlink RC received values to the arducopter internal corresponding variables.

The code is quite a mess and is not well commented (we were in a real hurry), 
so I'm sure you will have a lot of questions regarding the modifications. I 
would recommend to compare the modified files with the original ones to see 
clearly what I've done.

Original comment by robertop...@gmail.com on 4 Oct 2011 at 5:43

Attachments:

GoogleCodeExporter commented 8 years ago 
THX for helping
these file is useful to me

Original comment by zhwe...@gmail.com on 13 Oct 2011 at 6:30