Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

link diagnostics don't shows mavlink_state_t (all fields are 0) #269

Closed
vooon opened this issue Apr 9, 2015 · 4 comments
Closed

link diagnostics don't shows mavlink_state_t (all fields are 0) #269

vooon opened this issue Apr 9, 2015 · 4 comments
Labels
bug
Milestone
Version 0.12

Comments

@vooon
Copy link
Member

vooon commented Apr 9, 2015

Something changed in mavlink state counters and now it always zero.
In 0.8 as i remember that worked.
@vooon vooon added the bug label Apr 9, 2015
vooon added a commit that referenced this issue Apr 18, 2015
@vooon
libmavconn #269: add seq number to debug
a783930
@vooon vooon added this to the Version 0.12 milestone Apr 18, 2015
@vooon
Copy link
Member Author

vooon commented Apr 18, 2015

Very strange things happen with send seq numbers.
Example: 42, 43, 132, 44, 45, 133, 46, 134, 47....

Looks like there many instances of mavlink_status_t. Or it'is not synchronized among threads.
And i don't see easy way now. I can pull packet parser into interface and drop channel limitation in that part (instead of external storage, which requires channel number allocation, use class members).
And this will work with on input side (decode functions don't depend on mavlink_status_t), but not for output because encoding functions does: encode data, set headers including seq, calculates crc16.

@vooon vooon mentioned this issue Apr 18, 2015
Closed
vooon added a commit that referenced this issue Apr 18, 2015
@vooon
Merge branch 'master' into coverity_scan
1a2e421 
* master:
  plugin: param fix #276: add check before reset request downcounter.
  libmavconn #269: add seq number to debug
  gcs bridge fix #277: add link diagnostics
  vim: Add YouCompleteMe configuration file
  plugin: setpoint_position #273: add quirk for PX4.
  readme: fir glossary misprint
  readme: add notes about catkin tool
  0.11.1
  prepare release 0.11.1
  scripts #262: update mavwp
  scripts #262: mavsetp, new module mavros.setpoint
  mavftpfuse #129: done!
  mavftpfuse #129: cache file attrs
  mavftpfuse #129: initial import
This was referenced Apr 23, 2015
Closed
Closed
@vooon
Copy link
Member Author

vooon commented Apr 26, 2015

Trying to debug again (ohh, where gdb for dummies?) and i feel that it is definitely thread sync problem.

I see one seq stream for timesync (which i believe runs in first AsyncSpinner thread)
and different one for command_long 520, which runs in second thread because first blocks on RPC call to command plugin.

Before 0.11 there two threads: libmavconn receiver and ros spinner (callback executor), now we use AsyncSpinner with 4 threads.

@vooon
Copy link
Member Author

vooon commented Apr 26, 2015

Look more: it is stranger!

Looks like it per-plugin:

  • sys_time messages 111 & 2
  • sys_status: 0
  • command: 76
  • param: 21 & 20
  • waypoint: 43, 40, 47 - one seq
  • ftp: 110

@vooon vooon closed this as completed in 9a51161 Apr 26, 2015
@vooon
Copy link
Member Author

vooon commented Apr 26, 2015

Ok, now i think that problem comes from many inlined copies of mavlink_get_channel_status().

Upd: yes, that guess is true.

@vooon vooon mentioned this issue Apr 26, 2015
Merged
vooon added a commit that referenced this issue Apr 26, 2015
@vooon
Merge branch 'master' into coverity_scan
1023cdd 
* master:
  libmavconn fix #269: override default channel getter helpers
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
Version 0.12
Development

No branches or pull requests
1 participant
@vooon