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.

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

THRUSTERS: raise alarm on fatal thruster configuration #257

Closed
wants to merge 4 commits into from

Conversation

LucasBA
Copy link
Member

@LucasBA LucasBA commented May 15, 2017

#252 THIS IS NOT READY FOR MERGE. I added a thruster kill for when we lose two linearly dependent thrusters. I couldn't think of a way to test it without running it on the sub and unplugging thrusters so I figured I would just post this to show what I have so far and to see if anyone had any input.

Copy link
Contributor

@kev-the-dev kev-the-dev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got some Q's to be A'd about these implementations, but good stuff

pose command.
'''
for i in xrange(len(positions)):
yield self.sub.move.look_at_without_pitching(np.array(positions[i][0:3])).go(speed)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we look at the point first? I think the desired behavior is one move setting relative position and orientation from the current position. This lets the controller pick how to get to this pose.

pose = self.sub.pose
yield self.sub.move.relative(np.array(positions[0:3])).set_orientation(transformations.quaternion_multiply(
    self.sub.pose.orientation,
    transformations.quaternion_from_euler(orientations[i][0], orientations[i][1], orientations[i][2]))).go(speed)

update = rospy.ServiceProxy('update_thruster_layout', UpdateThrusterLayout)
rospy.wait_for_service('b_matrix')
try:
B = rospy.ServiceProxy('b_matrix', BMatrix)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this does what you want. This doesn't call the service, it returns an object to call it later. See rospy.ServiceProxy. Try:

# in __init__ so you only have to do this once
rospy.wait_for_service('b_matrix')
self.bmatrix_proxy = rospy.ServiceProxy('b_matrix', BMatrix)
...
#In alert_thruster_unloss
B = self.bmatrix_proxy() #You might have to put an empty BMatirxRequest() as an argument
B = numpy.asmatrix(B.B)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah thanks

@@ -312,6 +312,38 @@ def _run_look(self, spotings_req):

yield self.sub.nh.sleep(.5)

class PoseSequenceCommander(object):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer if this was refactored to calculate all the poses in the constructor and give the user control over when to run them. This would make it easy to plug into the Searcher class we have or other custom uses.
So something like:

def __init__(self, sub, positions, orientations):
    # Calculate poses into self.poses

def move(self, **kwargs):
   for p in pose:
        p.go(**kwargs)

},
severity=5
)
except rospy.ServiceException, e:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you need two try/except blocks? Could this all be in one block?

severity=5
)
except rospy.ServiceException, e:
print "Service call failed: %s"%e
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be a rospy.logwarn/rospy.logerr so it shows up in logs and should describe what service call is failing

def run(sub_singleton):
'''Used for testing in sim. These commands may not be safe for the real sub.'''
fprint("Starting Test With Eulers", msg_color="blue")
positions = [np.array([-1, 0, 0]), np.array([0, 0, 3]),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It'd be nice if I could just put normal ole' python arrays as the input to PoseSequenceCommander and it would convert to numpy for me so i don't have to type np.array a million times

@kev-the-dev
Copy link
Contributor

kev-the-dev commented May 22, 2017

A lot of these diffs are copied in #249. If you have multiple PRs in at once, try to have them both based on master so we don't have these duplicate diffs. Please rebase this ontop of master to only contain the changes to the thruster driver.

git fetch upstream/master
git rebase -i upstream/master
# in file that opens uncomment all commits but the last one.

@kev-the-dev kev-the-dev changed the title Degen THRUSTERS: raise alarm on fatal thruster configuration May 22, 2017
@kev-the-dev
Copy link
Contributor

What's up Lucas? If you rebase it to fix the git shenanigans we can run it in lab and see if it has the intended behavior.

@LucasBA
Copy link
Member Author

LucasBA commented Jun 5, 2017

I thought I fixed it but I am getting this c3 error when I catkin_make, Is this a known thing? Do I have something improperly configured?

/home/lucas/mil_ws/src/SubjuGator/legacy/c3_trajectory_generator/src/node.cpp: In member function ‘void Node::timer_callback(const ros::TimerEvent&)’:
/home/lucas/mil_ws/src/SubjuGator/legacy/c3_trajectory_generator/src/node.cpp:207:88: error: ‘const struct mil_msgs::MoveToGoal_<std::allocator >’ has no member named ‘blind’
goal->speed, !goal->uncoordinated, !goal->blind);
^
/home/lucas/mil_ws/src/SubjuGator/legacy/c3_trajectory_generator/src/node.cpp:215:21: error: ‘mil_msgs::MoveToResult {aka struct mil_msgs::MoveToResult_<std::allocator >}’ has no member named ‘error’
actionresult_.error = WAYPOINT_ERROR_TO_STRING.at(checkWPResult.second);
^
/home/lucas/mil_ws/src/SubjuGator/legacy/c3_trajectory_generator/src/node.cpp:216:21: error: ‘mil_msgs::MoveToResult {aka struct mil_msgs::MoveToResult_<std::allocator >}’ has no member named ‘success’
actionresult_.success = checkWPResult.first;
^
/home/lucas/mil_ws/src/SubjuGator/legacy/c3_trajectory_generator/src/node.cpp:285:21: error: ‘mil_msgs::MoveToResult {aka struct mil_msgs::MoveToResult_<std::allocator >}’ has no member named ‘success’
actionresult_.success = false;
^
/home/lucas/mil_ws/src/SubjuGator/legacy/c3_trajectory_generator/src/node.cpp:286:21: error: ‘mil_msgs::MoveToResult {aka struct mil_msgs::MoveToResult_<std::allocator >}’ has no member named ‘error’
actionresult_.error = WAYPOINT_ERROR_TO_STRING.at(WAYPOINT_ERROR_TYPE::OCCUPIED_TRAJECTORY);
^
SubjuGator/legacy/c3_trajectory_generator/CMakeFiles/c3_trajectory_generator.dir/build.make:86: recipe for target 'SubjuGator/legacy/c3_trajectory_generator/CMakeFiles/c3_trajectory_generator.dir/src/node.cpp.o' failed
make[2]: *** [SubjuGator/legacy/c3_trajectory_generator/CMakeFiles/c3_trajectory_generator.dir/src/node.cpp.o] Error 1
CMakeFiles/Makefile2:9243: recipe for target 'SubjuGator/legacy/c3_trajectory_generator/CMakeFiles/c3_trajectory_generator.dir/all' failed
make[1]: *** [SubjuGator/legacy/c3_trajectory_generator/CMakeFiles/c3_trajectory_generator.dir/all] Error 2
Makefile:138: recipe for target 'all' failed

@RustyBamboo
Copy link
Member

@LucasBA pull the latest mil_common

@LucasBA
Copy link
Member Author

LucasBA commented Jun 6, 2017

Thanks that worked

@LucasBA LucasBA force-pushed the degen branch 2 times, most recently from 8e159b6 to 2154fe6 Compare June 6, 2017 15:58
@sentree
Copy link
Member

sentree commented Jun 15, 2017

Is this still waiting on changes, or does @LucasBA just need to fix the formatting?

@LucasBA
Copy link
Member Author

LucasBA commented Jun 15, 2017

David made a bunch of changes to this file and is still working on it so he wanted to stabilize that before merging this

@sentree
Copy link
Member

sentree commented Jul 18, 2017

The GNC stack has been merged back in and seems fairly stable. Is there any chance this could be quickly brought up to date before competition or is it now a more involved project? It would definitely be a nice feature to have seeing as our thrusters appear to be dying weekly now...

@kev-the-dev
Copy link
Contributor

Archived at archive_pr_257

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants