Interaction board expansion

[HPovoa]

The interaction board ros api has been expanded. Clients may now control motor velocity. Aditionally, motor destinations may be sent with a single command. Increased speed on motor readings.

[ipa-nhg]

@HPovoa thanks for the update.

please remove the folders:

.catkin_tools
devel
share
logs

only the src code is needed

[ipa-nhg]

Looks good to me. @bajo could you please also review this PR? you have more experience with the interaction drivers

[bajo]

The changes look good. I have a deadline tomorrow, so I will only be able to test the code on the robot on Monday.

[ipa-nhg]

Thanks, I will wait until you test the hardware next week

[jibweb]

So I just started testing the pull request on the robot When I starts, spits out "incorrect motor position reads, using last known correct" continuously

• I can move the pan and tilt and head with /neck_pan_controller/command, /neck_tilt_controller/command and /head_controller/command respectively
• I couldn't figure out how to use the /head_and_neck_controller with its multiarray from the command line
• The /mouth/command works as expected
• The /light/command works but only turns on the leds in the front (is that a feature or a bug ?)

Anything else I should test ?

[HPovoa]

The 'using last known correct' log is expected, it was a test i was making and i forgot to remove it, but the values published should have enough precision.

The python script test_squirrel shows how you can move all motors at once with a single publication.

Basically you send an array of 3 floats. Only the data field of std_msgs/Float64MultiArray message is used. These are destinations (in radians) for the head, neck pan and neck tilt (in that order). Using the command line:

rostopic pub /head_and_neck_controller/command std_msgs/Float64MultiArray "layout: dim:

• label: '' size: 0 stride: 0 data_offset: 0 data: [0.2, 1.0, 0.0]" -1

Also, please bear in mind the limitations of the motors, as defined in the file serial_api.py

All leds should change color, i'll have to test that on ours.

Let me know if you have any other questions!

[mzillich]

HI, can this be merged now?

[ipa-nhg]

if it is ok for @jibweb , yes!

[jibweb]

Not really right now, I'm still unsure why we don't have all the base leds turning on anymore ?

[bajo]

@jibweb Can you check if we at least have the correct motor values? So, if you move the neck/head does the tf update accordingly?

[jibweb]

@HPovoa : Any ideas, thoughts or things to test out to figure out why we only have a tenth of the leds at the base that light up ? It seems to have started as soon as we flashed the new board firmware, but I can't say for sure which part is at fault right now

[HPovoa]

@jibweb i'll be publishing a new version later on today that you can test. But your issue seems strange. Which leds are they?

[jibweb]

only the leds that you can see are lighting up

[HPovoa]

I'm uploading a new version now.

Can you change their colors freely? Would you show me the command you are using?

[jibweb]

the color works yes, but can't get them all to work with:

rostopic pub /light/command std_msgs/ColorRGBA "r: 0.0 g: 0.0 b: 255.0 a: 0.0"

[jibweb]

Also a typo at l.245 in board.py "colors" should be "color"

[jibweb]

What would be the easiest to figure out if the board firmware we have is indeed responsible for the leds issues ? Knowing that Innsbruck supposedly have the same firmware (but there might still be minor differences?) and it doesn't happen there.

[HPovoa]

you're right about the typo. you can use the other topic, light_complex, send it UInt16MultiArray(data=[255] * 126).

you can also go down a level, kill the /board node and roscd into squirrel_interaction/src/squirrel_interaction/board

open up a python console and type

from serial_api import Controller c = Controller('/dev/ttyBoard') colors = [255] * 126 c.set_base_led_colors(colors)

if that still only lights up the first 5 leds, i believe the led array is damaged. Tilt squirrel and take a look, sometimes you can see these problems

[HPovoa]

The easiest way to test if the firmware is the problem is to get an arduino with a led array test program and plug it into the led array. I can point you to the one our electronics people use

[HPovoa]

Take a look at this link led array hookup guide It explains how you can set it up. There is a link to the github repo with the test programs. bear in mind that some of these test programs might need you to specify how many leds your array has, just give it 200.

But also take a glance at the leds, if there is anything physically wrong with it, you might be able to tell with the naked eye

[jibweb]

Tried the snippet you sent using directly the controller from serial_api and the same behavior is observed, still only the first 5 leds light up

Looking directly at the leds, we could see that it stopped working between the 5th and 6th led, and both of those are on the same pcb, so the failure is not a faulty connection and so quite unlikely to be hardware related !

So there is a pretty decent chance that the firmware is the part that is not working here. I'll try the arduino test as soon as possible and let you know

[jibweb]

[HPovoa]

The arduino test is the best chance i see to figure out what the problem is for certain. Did you observe any other issue? where the readings from the motors accurate enough?

[mzillich]

Motor readings seem fine as far as I can tell with the naked eye.

Another issue was the door. It behaved strange. E.g. when it hit the "open" switch it would go back and close again.Then it went past the "closed" switch once (the switch was mechanically not pressed properly) and then we could not get it to open again. It would keep trying to close. In the end we had to take off the string attachments and the motor to disentangle the string. So for now we run the robot with the door removed. Once everything else works (improved shell mounting etc.) we will fix the string and put it back on.

We did not have time btw to make those shell mounting improvements. Hope to get it done over the weekend.

[jibweb]

So in the end, with the arduino test (thanks for the link) we could check that it was a hardware problem It must have happened when transporting because there is no other place than below the base to hold the robot when the shell is on, so we'll fix that soon.

Regarding the interface, it crashes once in a while with

Traceback (most recent call last):                                           
  File "/u/vienna/board_ws/src/squirrel_driver/squirrel_interaction/src/squirrel_interaction/board/board.py", line 280, in <module>                   
    controller.run()                                                                                  
  File "/u/vienna/board_ws/src/squirrel_driver/squirrel_interaction/src/squirrel_interaction/board/board.py", line 98, in run      
    joint_state_msg.position = map(radians, positions)                                            
TypeError: a float is required

So just testing if positions is None is not enough, although I'm not sure what it gets when it crashes, I couldn't reliably make that happens so far

[ipa-nhg]

I think this PR is out-of-date.. @jibweb should it be closed?

[jibweb]

Actually, most of the issues we had were hardware related, so it seems this PR is fine. We've been testing it for a while without facing issues anymore !

[ipa-nhg]

There is a merge conflict with the current squirrel_project version, @jibweb could you please commit and open a pull request with the current working version on the robot? To be sure that we merge it correctly!

Thanks!

[jibweb]

Actually, the status on the robot is the same as here, we kept a separate workspace for the board !