Integration

[fwalch]

See the integration wiki page. This is for discussing the contents.

One idea I had when creating the page: Maybe it would be better to have a third node (in addition to "CV"/navigation node) that has the state machine and sends commands (probably via a ROS service call, i.e. remote function call) to the other nodes, i.e. "navigation node: take off", "navigation node: fly to site", "vision node: start performing mission and send deltas to navigation node"? opinions?

[efiShtain]

I think that is the main purpose of the navigation module Maybe the name isn't correctly indicating capabilities It suppose to has a state machine that will handle all of that

נשלח מה-iPad שלי

‫ב-25 במאי 2015, בשעה 07:19, ‏‏Florian Walch ‏notifications@github.com כתב/ה:‬

See the integration wiki page. This is for discussing the contents.

One idea I had when creating the page: Maybe it would be better to have a third node (in addition to "CV"/navigation node) that has the state machine and sends commands (probably via a ROS service call, i.e. remote function call) to the other nodes, i.e. "navigation node: take off", "navigation node: fly to site", "vision node: start performing mission and send deltas to navigation node"? opinions?

— Reply to this email directly or view it on GitHub.

[fselius]

If I understand correct - a 3rd node will monitor current mission status and decide when it's time to transition to the next part of the mission. E.g. we start off with takeoff, once altitude is 3m the state machine will transition to fly to site, once GPS error is under 3m transition to search for balloon, once the balloon is found transition to kill balloon, etc. Each node (CV/navigation/other) will have several states, the CV node would do nothing on takeoff and fly to site, run Algorithm A for search for balloon and Algorithm B for kill balloon. Did I understand correct @fwalch ? Would the states be global? That is could different nodes be in different states at the same time?

[fselius]

I want to add that you guys are doing an excellent job, not just at your specific tasks, but also thinking about the system as a whole. What are the strengths, weaknesses, problems that might come up, how to deal with said weaknesses and problems. You are paving the road for a modular, portable and robust system.

[fwalch]

Did I understand correct @fwalch ?

Yes, that was basically the idea. Ro'ee and me discussed it, and we think the navigation node could probably be implemented just having a single state ("listen to /pid_input and fly there until the input is zero") and a service ("reset PID controllers", called when switching to new waypoints). Maybe we need additional services for arm/disarm/....

The state machine could just entirely live in the "CV" node. For example, for take-off, we can read the input from a height sensor and publish a Δz until we reach the target height. For flying to the mission site, we can publish Δx and Δy by subtracting the movements after take off (from GPS) from a specified fixed offset (which we measured the day before the competition).

So we wouldn't need a third "state node" (actually, we already have a third node, which is the mavros_node).

I updated the Integration page with this.

[noamyogev84]

Take a look at the navigator module guys, implemented SetCurrentMode service which accepts mode and additional param (string,whatever). so basically look for this service :

and pass it the params you want. (e.g rosservice call /navigator/set_mode 2 takeoff - means take off to 2 feet and hold altitude)

look at all other options, and tell me what do you think is missing. @fwalch @efiShtain @roeemz @Vasily

[noamyogev84]

Dry experiment of the navigation system at the lab 13.6.2015

Tasks performed:

• Invoking all relevant processes on the odroid via ssh including Mavros, Navigator, PID, KeyboardSimulator - success
• Tested Human Override functionality with different scenarios (on the ground, during publish) - success
• Tested the KeyboardSimulator - changed z error values -> sent to PID -> navigator published and increased/decreased throttle.

Issues we solved:

• In order to give back control to RC, ResetRCChannels method MUST release all channels and give them the value 0 (RELEASE).
• Command rosrun mavros mavsys rate --all 25 must be invoked at startup - need to add it to the launch file probably.

Observations:

• The system is slow, we need to understand the scheduling between processes (e.g writing at another terminal commands while PID,Navigator running and publishes is significantly slow)
• It seemd that there is a delay of ~1sec from the moment we trigger human override channel, until RC is functioning again.

Next Experiment:

• Wet experiment with props - maintaining altitude manually and changing ROLL with KeyboardSimulator ->PID ->Navigator.

[fselius]

How many processes/nodes are running? Did you check CPU/Ram/disk usage? A slow-responding system and particularly, 1 second delay for human override, isn't acceptable.

[serbuh]

My conclusions regarding today's and further tests: My point of view can be a bit overprotective towards the quad (cause I know the price ($ and time:) ). I think that we shouldn't conduct tests that have a relatively big probability of crashing the copter. If we would have a crash from 1-2 meters so probably we will need to replace some parts, that means that we will have to wait for the shipping, that means that we will lose time. In other words: safety first. So:

• I think that 1 second delay issue has higher priority than conducting the test itself.
• Important today's bug: "instead of full control back to the RC we had some channels frozen". The bug was eliminated. But that doesn't promise that it won't come back. I think we should test our safety mechanism in different ways before doing the full wet test. I.e. we should dedicate time for a test of the mechanism (for example, the PC changes the mode to altHold, and then RC retakes control. Maybe we should try different modes, repeat it a number of times (stress test))
• Another bug: in Pixhawk a number of RC channels became frozen even when we disconnected the PC o_O . Could be a problem with RC (we turned on RC after turning on the Pixhawk). We didn't reproduced a bug again. That just strengthen the need in stress tests.
• HUD development. I see the need in a simple GUI HUD with basic information such as Flight mode, RC input, altimeter, etc. It gives basic information that helps to understand the copter's behavior and helps to debug problems faster especially at early stages of development. Noam agreed to create a basic ROS node that will be responsible for the HUD. I and Alex will help to write a code for the GUI.

Regarding the flight test with new props: First kind of new props (don't remember which size are they) doesn't fit our motors. Maybe we could use prop adapters from our own copter. We need to check if they fit. The other kind of props are seems to be Ok, I flew the quad, but I felt a difference. The quad was much more sensitive. It can make a difference if we will give control to the PC. The copter's reactions are more sharp. Need to test them with the automated flight.

And I want to mention that Noam did a great work today, eliminating the bugs in code and logic!

[fselius]

Completely agree with first to third bullets, we can't afford to crash at this stage. Regarding HUD - Can't say I like the idea of another ROS node, I suspect its adding delays all around. Plus we got bigger fish to fry, bash script to print relevant topics won't do? Flight test - new issue.