Closed Aamanen closed 6 years ago
I think you understood everything correctly, your procedure seems to be all right. Anyway, the error seems to happen in the RateEncoder
and it's a bit mysterious.
I'm a bit suspicious about the received data from the joint_state_publisher
. There could be an issue with the scaling of the data, as the RateEncoder
expects input in the range between -1 and 1. I guess the positions of the joints can be between -pi and pi, right?
If this is the case, could you please replace both 1
in fable_converge_weights2.txt
with 0.318
(1 / pi) and let me know if that changes things?
Again that seemed to do the trick @weidel-p ! It was exactly as you say: the Joint_state_publisher was sending data exceeding the -1 to 1 limit and caused the crash. Replacing the weights in fable_converge_weights2 to 1/pi solved the problem. I'm once again very thankful for your help!
Great! I'm happy that I can help.
Hi just a not-so-well-founded quick input from me:
Looking at the backtrace, I get the impression that this is due to memory corrution. This could be inside MUSIC. (I have recently committed fixes inserting missing virtual destructors---please update to master HEAD.) But it is more likely in the other code.
Philipp: Are there range checks in the adapters such that it is impossible to trash memory, given the wrong parameters?
Den 27 okt 2017 10:48 skrev "weidel-p" notifications@github.com:
I think you understood everything correctly, your procedure seems to be all right. Anyway, the error seems to happen in the RateEncoder and it's a bit mysterious.
I'm a bit suspicious about the received data from the joint_state_publisher. There could be an issue with the scaling of the data, as the RateEncoder expects input in the range between -1 and 1. I guess the positions of the joints can be between -pi and pi, right? If this is the case, could you please replace both 1 in fable_converge_weights2.txt with 0.318 (1 / pi) and let me know if that changes things?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/INCF/MUSIC/issues/50#issuecomment-339912589, or mute the thread https://github.com/notifications/unsubscribe-auth/ADcfCeI9nteun4gFRbqI1ufFvwl4ZhHcks5swZjxgaJpZM4QH2hw .
I'm trying to read the positions of 2 joints from the topic /joint_states as known from http://wiki.ros.org/joint_state_publisher. These positions i want to feed to my neurons in NEST and they will respond by publishing a torque to topic /jointgroupeffort/command.
In this effort I'm having issues with converging from arrays generated by the publisher /jointstates into just 2 inputs to NEST. In doing so I have followed the example with the braitenberg vehicle where the "braitenberg3_converge_weights.dat"
braitenberg3_converge_weights.txt
converges 20 elements into 2 elements, by splitting the 20 elements into 1/20'th parts. Either I have misunderstood the procedure from the Braitenberg example, or I assume a wrong structure of data published in the /jointstates. This is my converging weight file fable_converge_weights2.txt Where i try to single out the position of the first joint and the position of the second joint. music file: fablenew5.txt
When running the simulations I get this error, which I don't receive when using the "braitenberg3_converge_weights.dat" in the same simulation.