Implement transition to fw as an action. #150

xgerrmann · 2017-11-03T14:41:01Z

Implementation of the transition to Fixed Wing from VTOL.
One problem: It only builds if the action header files in the install directory contain the correct definitions. I did not include these files since the directory is placed in the .gitignore.

Checks to perform prior to acceptance:

Test how commands behave if used in wrong modes or on wrong vehicles and confirm docs match that.

julianoes

Cool, thanks for the contribution!

I left comments concerning docs and naming.

Also, it would be good if you could add an integration test to try that in SITL.

And I'm assuming you also want to add a command to transition back?

julianoes · 2017-11-03T14:45:14Z

plugins/action/action.h

@@ -119,6 +119,13 @@ class Action
    Result return_to_launch() const;

    /**
+     * @brief Send command to *change flight mode* (FW).


Please describe what this does for an outsider that doesn't know the concept of flight modes and neither the acronym FW.

And also comment that this is only applicable for hybrid/VTOL vehicles.

julianoes · 2017-11-03T14:46:06Z

plugins/action/action.cpp

@@ -42,6 +42,11 @@ Action::Result Action::return_to_launch() const
    return _impl->return_to_launch();
 }

+Action::Result Action::transition_to_fw() const


I'm tempted to suggest to rename this to transition_to_fixedwing. The goal is to have an easy to use, and self explanatory API. I would error on the side of verbosity.

coveralls · 2017-11-03T15:04:21Z

Coverage remained the same at 55.131% when pulling baf2b1d on xgerrmann:transition_to_fw into 50a09fc on dronecore:develop.

julianoes · 2017-11-03T15:25:58Z

@xgerrmann I'm to blame for failing CI. Working on it...

julianoes · 2017-11-03T15:27:14Z

@xgerrmann for your build problems:

It should build just fine if you remove what you have installed, and just do make default.

hamishwillee · 2017-11-05T21:56:51Z

@xgerrmann @julianoes

How do you transition back to MC mode? IMO this should probably have a boolean to indicate the mode (although I guess you could do a matching transition to mc method.
There should be a matching method, probably in Telemetry to get the current mode.
There should be a corresponding async method to match the sync method.

xgerrmann · 2017-11-05T23:39:12Z

@julianoes @hamishwillee
Thanks for your comments.
I've implemented the switch back to multicopter as transition_to_multicopter();
One problem I'm running into is that the device.action().transition_to_fixedwing() is giving met timeouts as result, thus Action::Result::Timeout. It seems there is no acknowledgement from the VTOL, any ideas on this?

julianoes · 2017-11-06T14:34:02Z

One problem I'm running into is that the device.action().transition_to_fixedwing() is giving met timeouts as result, thus Action::Result::Timeout. It seems there is no acknowledgement from the VTOL, any ideas on this?

Ok, does the transition happen when you try it in SITL?

julianoes · 2017-11-06T16:35:39Z

@xgerrmann Can you please remove the install folder that you checked in from this PR?

julianoes

Please remove branchfile, install directory, best with git rebase -i because the binary lib file should not be in the git history.

coveralls · 2017-11-06T18:16:52Z

Coverage decreased (-37.6%) to 17.571% when pulling 279a771 on xgerrmann:transition_to_fw into 50a09fc on dronecore:develop.

xgerrmann · 2017-11-06T19:39:11Z

I've added an example now for the transition between multicopter and fixedwing. In the mean time I rebased on the latest head of the develop branch. I removed the install directory from the git, since I now know how to correctly install with 'make default install'.

Timeouts still occur in the example, I switched off the 'return 1', so that the actions still are performed. So it seems like the requested behaviour is performed, but with timeout errors from MAVLINK.

coveralls · 2017-11-06T19:52:29Z

Coverage decreased (-37.6%) to 17.571% when pulling 072c459 on xgerrmann:transition_to_fw into 50a09fc on dronecore:develop.

mrpollo · 2017-11-06T19:55:54Z

@xgerrmann once @julianoes is done with his review can you please do some cleanup with your commits? perhaps merging some of them with an interactive rebase, I want to encourage better commit titles and messages

mrpollo

There seem to be lots of changes not related to the intended changeset which makes it complicated to review for me @xgerrmann, if its ok with you @julianoes I'm gonna leave this one out to you to review, please ping me if you need my help

coveralls · 2017-11-06T20:01:43Z

Coverage decreased (-37.6%) to 17.571% when pulling e90c0b9 on xgerrmann:transition_to_fw into 50a09fc on dronecore:develop.

xgerrmann · 2017-11-06T20:06:57Z

@mrpollo Ill clean it up >tomorrow<. So please don't bother checking until then.
Thanks for checking it out.

coveralls · 2017-11-06T20:43:34Z

Coverage decreased (-37.6%) to 17.571% when pulling 5269a14 on xgerrmann:transition_to_fw into 50a09fc on dronecore:develop.

coveralls · 2017-11-06T22:29:39Z

Coverage decreased (-37.6%) to 17.571% when pulling 75b68f7 on xgerrmann:transition_to_fw into 50a09fc on dronecore:develop.

coveralls · 2017-11-06T22:37:41Z

Coverage decreased (-37.6%) to 17.571% when pulling 5f28f79 on xgerrmann:transition_to_fw into 50a09fc on dronecore:develop.

hamishwillee · 2017-11-06T23:14:45Z

plugins/action/action.h

@@ -119,6 +119,26 @@ class Action
    Result return_to_launch() const;

    /**
+     * @brief Send command to transition the drone to fixedwing.
+     *
+     * Note that this is only for the vtol type.


Suggest replace both of these points (and update similarly elsewhere) to:

The associated action will only be executed for VTOL vehicles in multicopter mode.
On other vehicles/modes the command will fail with a Result.

I assume that the statement is correct - ie that the command will fail with an error?

hamishwillee · 2017-11-06T23:16:36Z

I'm going to go so far as to suggest you abandon this PR and re-add to latest develop - a lazy man's rebase. There are just too many "accidental" changes in here for anyone to be sure it is safe to acccept.

The method signatures look OK to me. I have added comment inline about document improvement. Can we also get current VTOL mode added to telemetry? @julianoes Would be good to hear your ideas on best way to do this - as part of a VTOL info class or something more generic?

coveralls · 2017-11-07T00:06:26Z

Coverage decreased (-37.6%) to 17.571% when pulling 4934183 on xgerrmann:transition_to_fw into 50a09fc on dronecore:develop.

xgerrmann · 2017-11-07T14:15:43Z

Ok guys, I squashed the commits. It's much cleaner now :)
Just try to run the example and you'll notice the timeout errors.

Now working on a test script

coveralls · 2017-11-07T14:32:13Z

Coverage remained the same at 17.571% when pulling 84bc5e1 on xgerrmann:transition_to_fw into 1b176f3 on dronecore:develop.

hamishwillee · 2017-11-07T22:46:55Z

plugins/action/action.h

@@ -187,6 +207,26 @@ class Action
    void return_to_launch_async(result_callback_t callback);

    /**
+     * @brief Send command to transition the drone to fixedwing (asynchronous).
+     *
+     * Note that this is only for the vtol type.


Argg, my comment from yesterday lost. Can you check your email for my suggested wording?

Found it :) Next commit will include your comment.

Thanks. Looks good. We will need to test that the comment is actually true once the timeout is fixed :-)

hamishwillee · 2017-11-08T00:16:08Z

As per this note it is a good idea to first write integration tests BEFORE writing example code. You'll need them anyway!

@julianoes I ran this, and the standard retries/timeout code is indeed being shown. What is interesting though is that the commands are being obeyed - ie the transition is happening. So either the ack is not being sent or it is being handled incorrectly.

Such a pity that logging isn't enabled so we could check all the traffic and see if "something" is really coming back. Any ideas on debugging?

xgerrmann · 2017-11-08T10:01:53Z

In the latest commit, I've implemented an integrationtest.
The same problem with the acknowledgement, still occurs.
I've been searching for a MAVLINK message that asks for the state of the vtol (multicopter or fixedwing), so that in the test script I can check wether the states are correct and put it in an EXPECT, but so far I have not been able to find such a state request message.
Any ideas on:

How to request the multicopter or fixedwing state?
How to solve the acknowledgement problem?
@julianoes

julianoes · 2017-11-08T18:48:33Z

@xgerrmann thanks a lot. I will look into the issues. I might not get to it today I'm sorry but definitely tomorrow.

hamishwillee · 2017-11-08T23:22:16Z

plugins/action/action.h

@@ -119,6 +119,26 @@ class Action
    Result return_to_launch() const;

    /**
+     * @brief Send command to transition the drone to fixedwing.
+     *
+     * The associated action will only be executed for VTOL vehicles in multicopter mode.


Thanks! This will need to be checked of course (once we have got the timeout issue fix). It may be that PX4 would simply ignore the command if sent while already in the current mode (rather than fail) and similarly it might ignore the command for non vtol rather than failing it.

@julianoes So based on your change PX4/PX4-Autopilot#8264 would I be correct in saying that

on a vtol vehicle the result will either be "success" or timeout, where success is an ack of message received, not that the vehicle will act on it? In other words, if you're already in FW and you call this it will just succeed?

What will happen on an MC or FW only vehicle - will your added code still get run? If so, then basically this will return success if received by vehicle, which will be a bit odd on MC. Should our code therefore check the type of vehicle we're talking to before even sending the message?

on a vtol vehicle the result will either be "success" or timeout, where success is an ack of message received, not that the vehicle will act on it? In other words, if you're already in FW and you call this it will just succeed?

correct, it will just succeed.

What will happen on an MC or FW only vehicle - will your added code still get run? If so, then basically this will return success if received by vehicle, which will be a bit odd on MC. Should our code therefore check the type of vehicle we're talking to before even sending the message?

It will just time out because the VTOL controller is not running and therefore not responding.

A check to see if it is actually a VTOL and a specific error message for it would be nice!

@xgerrmann So

Can we check this is VTOL and have a specific error message for other types (rather than getting timeout).

So the text needs to change slightly as a result of Julian's feedback:
The associated action will fail with a Result if called for non-VTOL vehicles The action is ignored if called when the vehicle is in fixed-wing mode mode.

@julianoes What about if someone is using firmware pre your fix? Should we also have a PX4 version check?
The problem here is that even in an old version we always want to send the message, resulting in the timeout. But in an old version we want to ignore the ack result. To me that sounds like we want to have a version of our send that if we don't get an ack on we can force to succeed anyway. THoughts?

hamishwillee · 2017-11-08T23:33:59Z

How to request the multicopter or fixedwing state?

Without having actually tried it, using EXTENDED_SYS_STATE

julianoes · 2017-11-09T21:35:20Z

Ok, I'm debugging the missing ack and writing down my steps as suggested by @hamishwillee:

I check out the PR:

cd DroneCore
make clean
git fetch origin pull/150/head:pr_150
git checkout pr_150
make

I look for the new integration test:

make && build/default/integration_tests_runner --gtest_list_tests

Ok found it let's run it:

make && build/default/integration_tests_runner --gtest_filter="SitlTest.ActionSimpleTransition"

And of course run px4 latest master:

cd Firmware
make clean
git checkout master
git fetch
git merge
git submodule update --init --recursive
make posix gazebo_standard_vtol

I can reproduce the missing ack:

[04:00:24|Info ] sending again, retries to do: 3  (3000). (mavlink_commands.cpp:184)
[04:00:24|Info ] sending again, retries to do: 2  (3000). (mavlink_commands.cpp:184)
[04:00:25|Info ] sending again, retries to do: 1  (3000). (mavlink_commands.cpp:184)
[04:00:25|Error] Retrying failed (3000) (mavlink_commands.cpp:202)

Command 3000 is indeed MAV_CMD_DO_VTOL_TRANSITION.

Let's grep where this command is handled in Firmware:

rg MAV_CMD_DO_VTOL_TRANSITION src
src/modules/mavlink/mavlink_mission.cpp
1437:		case MAV_CMD_DO_VTOL_TRANSITION:

This seems wrong because we're not interested in mission items.

Let's look for just DO_VTOL_TRANSITION instead:

rg DO_VTOL_TRANSITION src 
src/modules/vtol_att_control/vtol_att_control_main.cpp
484:	if (_vehicle_cmd.command == vehicle_command_s::VEHICLE_CMD_DO_VTOL_TRANSITION) {

src/modules/mavlink/mavlink_mission.cpp
1437:		case MAV_CMD_DO_VTOL_TRANSITION:
1511:		case NAV_CMD_DO_VTOL_TRANSITION:

src/modules/commander/commander.cpp
564:			.command = vehicle_command_s::VEHICLE_CMD_DO_VTOL_TRANSITION,
1185:	case vehicle_command_s::VEHICLE_CMD_DO_VTOL_TRANSITION:

src/modules/navigator/mission_feasibility_checker.cpp
292:		    missionitem.nav_cmd != NAV_CMD_DO_VTOL_TRANSITION) {

src/modules/navigator/mission_block.cpp
98:	case NAV_CMD_DO_VTOL_TRANSITION:
636:		vcmd.command = NAV_CMD_DO_VTOL_TRANSITION;

src/modules/navigator/rtl.cpp
204:			_mission_item.nav_cmd = NAV_CMD_DO_VTOL_TRANSITION;

src/modules/navigator/navigation.h
88:	NAV_CMD_DO_VTOL_TRANSITION = 3000,

src/modules/navigator/mission.cpp
641:			_mission_item.nav_cmd = NAV_CMD_DO_VTOL_TRANSITION;
695:			_mission_item.nav_cmd = NAV_CMD_DO_VTOL_TRANSITION;
753:		if (_mission_item.nav_cmd == NAV_CMD_DO_VTOL_TRANSITION
781:		if (_mission_item.nav_cmd == NAV_CMD_DO_VTOL_TRANSITION
984:	    || _mission_item.nav_cmd == NAV_CMD_DO_VTOL_TRANSITION
1021:		    && !(_mission_item.nav_cmd == NAV_CMD_DO_VTOL_TRANSITION || _navigator->get_vstatus()->in_transition_mode)) {

Let's look at the controller itself first:
https://github.com/PX4/Firmware/blob/master/src/modules/vtol_att_control/vtol_att_control_main.cpp#L484-L486

Looks like the command is just not acked at all. Let's change that:
PX4/PX4-Autopilot#8264

julianoes

A couple of small comments, then we can merge this!

julianoes · 2017-11-09T21:36:06Z

CMakeLists.txt

@@ -143,7 +143,7 @@ add_library(dronecore ${library_type}
 target_link_libraries(dronecore
    ${CMAKE_THREAD_LIBS_INIT}
    ${curl_lib}
-    tinyxml2
+#    tinyxml2


Please don't change this stuff. Make sure to either merge or rebase on current develop and get rid of this diff.

I'd say rebase

julianoes · 2017-11-09T21:36:36Z

example/transition_vtol_fixed_wing/CMakeLists.txt

+else()
+    add_definitions("-std=c++11 -WX -W2")
+    set(platform_libs "Ws2_32.lib")
+endif()


Once you merge or rebase you will see that this file gets a lot simpler.

The required changes are being documented in mavlink/MAVSDK-docs#62 (in progress). The interesting bit is here - basically we're changing to use system-wide install by default AND dronecore itself is now linking to the thread library - so you no longer need to do most of this work.

julianoes · 2017-11-09T21:36:53Z

example/transition_vtol_fixed_wing/transition_vtol_fixed_wing.cpp

+	// Wait
+	std::this_thread::sleep_for(std::chrono::seconds(10));
+
+    // Change to VTOL


julianoes · 2017-11-09T21:38:19Z

integration_tests/transition_multicopter_fixedwing.cpp

+
+	Device &device = dc.device();
+
+	// Takeoff


I would get rid of comments that are identical to a function name. They don't add any information. I suggest only to add comments if you need to explain something, add additional info for the reader, e.g. We need to takeoff first, otherwise we can't actually transition 😄

julianoes · 2017-11-09T21:38:52Z

integration_tests/transition_multicopter_fixedwing.cpp

+    std::this_thread::sleep_for(std::chrono::seconds(wait_time_s));
+
+
+    EXPECT_GT(device.telemetry().position().relative_altitude_m, altitude_m - 0.25f);


Nice check, that will be useful once these integration tests make it into the PX4 Firmware testing.

Thanks, but I have to give credit where due. I got it from the simple_hover example ;)

julianoes · 2017-11-09T21:39:50Z

plugins/action/action_impl.cpp

+               _parent->send_command_with_ack(
+                   MAV_CMD_DO_VTOL_TRANSITION,
+                   MavlinkCommands::Params {float(MAV_VTOL_STATE_FW)},
+                   MavlinkCommands::DEFAULT_COMPONENT_ID_AUTOPILOT));


Yeah, that's it. I like that you added both sync and async methods, thanks!

coveralls · 2017-11-10T14:20:43Z

Coverage remained the same at 17.571% when pulling 03edbcc on xgerrmann:transition_to_fw into 762c327 on dronecore:develop.

xgerrmann · 2017-11-10T14:26:13Z

@julianoes I Really liked how you've written down your steps, this gives insight in your workflow and results in learning opportunities for people reading along (referring to myself here).

coveralls · 2017-11-10T14:32:54Z

Coverage remained the same at 17.571% when pulling 4abc5bb on xgerrmann:transition_to_fw into 670b15f on dronecore:develop.

coveralls · 2017-11-10T14:43:57Z

Coverage remained the same at 17.571% when pulling 1f59b88 on xgerrmann:transition_to_fw into 670b15f on dronecore:develop.

coveralls · 2017-11-10T14:57:23Z

Coverage remained the same at 17.571% when pulling 8ab64f6 on xgerrmann:transition_to_fw into 670b15f on dronecore:develop.

coveralls · 2017-11-10T15:13:52Z

Coverage remained the same at 17.571% when pulling 8ab64f6 on xgerrmann:transition_to_fw into 670b15f on dronecore:develop.

coveralls · 2017-11-10T15:28:00Z

Coverage remained the same at 17.571% when pulling 5b495fc on xgerrmann:transition_to_fw into 670b15f on dronecore:develop.

hamishwillee · 2017-11-13T00:34:34Z

integration_tests/transition_multicopter_fixedwing.cpp

 	device.action().transition_to_fixedwing();
+
+	// Wait a little before the transition back to multicopter,


And noting that we need to update to check transition once that is in place.

example and also implement async.

example and also implement async. Include an integration test.

…ents.

coveralls · 2017-11-13T17:16:54Z

Coverage remained the same at 17.571% when pulling 358234c on xgerrmann:transition_to_fw into 3f51147 on dronecore:develop.

mrpollo · 2017-11-13T18:36:49Z

@hamishwillee I really liked @julianoes short write up, can we find it a home in our docs?

hamishwillee · 2017-11-13T21:54:37Z

@mrpollo

@hamishwillee I really liked @julianoes short write up, can we find it a home in our docs?

I already created mavlink/MAVSDK-docs#63 to track this. It is not as easy as you might think to turn this into useful generic advice.

mrpollo

👍 thanks for the contribution 💯

hamishwillee · 2017-11-14T04:04:02Z

IMO there are a number of comments still not addressed.

Example uses old CMakeLists: https://github.com/dronecore/DroneCore/pull/150/files#r150093535
No API to get the current FW/MC state: Implement transition to fw as an action. #150 (comment)
- And if it exists to update the example appropriately.
Can we compensate for old firmware: Implement transition to fw as an action. #150 (comment)
Comments in the example vs console output: https://github.com/dronecore/DroneCore/pull/150/files#r150733221

hamishwillee · 2017-11-14T04:07:04Z

example/transition_vtol_fixed_wing/transition_vtol_fixed_wing.cpp

+    // Wait
+    std::this_thread::sleep_for(std::chrono::seconds(5));
+
+    // Return to launch


Actions in examples should be output to console rather than commented so that users have something to watch in the console. So "arming", "Taking off", "Landing", "Returning" etc.

* Implementation of multi-copter to fixed-wing and vice versa. * Include an example and also implement async. * Make integration test. * Add more descriptive prints and comments. * Remove non-informative comments. * run make fix_style * deleted zero byte file (was by mistake still present)

minor fixes for MAVSDK-Java autogen

julianoes requested changes Nov 3, 2017

View reviewed changes

julianoes requested changes Nov 6, 2017

View reviewed changes

mrpollo requested changes Nov 6, 2017

View reviewed changes

hamishwillee reviewed Nov 6, 2017

View reviewed changes

hamishwillee mentioned this pull request Nov 6, 2017

Add explicit support for VTOL #140

Closed

hamishwillee reviewed Nov 7, 2017

View reviewed changes

hamishwillee reviewed Nov 8, 2017

View reviewed changes

julianoes mentioned this pull request Nov 9, 2017

vtol_att_control: ack transition commands PX4/PX4-Autopilot#8264

Merged

julianoes reviewed Nov 9, 2017

View reviewed changes

hamishwillee mentioned this pull request Nov 9, 2017

Add debugging topic mavlink/MAVSDK-docs#63

Open

hamishwillee reviewed Nov 13, 2017

View reviewed changes

xgerrmann and others added 6 commits November 13, 2017 16:58

Implementation of multicopter to fixedwing and vice versa. Include an

bb7165c

example and also implement async.

Make integration test.

4a9ef89

Implementation of multicopter to fixedwing and vice versa. Include an

91e224a

example and also implement async. Include an integration test.

Add more descriptive prints and comments. Remove non-informative comm…

28c94b5

…ents.

run make fix_style

1391e94

deleted zero byte file (was by mistake still present)

358234c

julianoes approved these changes Nov 13, 2017

View reviewed changes

mrpollo approved these changes Nov 14, 2017

View reviewed changes

mrpollo merged commit 6f1c940 into mavlink:develop Nov 14, 2017

hamishwillee reviewed Nov 14, 2017

View reviewed changes

julianoes mentioned this pull request Nov 14, 2017

Follow up for VTOL transition additions #163

Merged

dlech pushed a commit to dlech/MAVSDK that referenced this pull request Jan 14, 2022

Merge pull request mavlink#150 from mavlink/java-fixes

6dfc909

minor fixes for MAVSDK-Java autogen

		std::this_thread::sleep_for(std::chrono::seconds(wait_time_s));


		EXPECT_GT(device.telemetry().position().relative_altitude_m, altitude_m - 0.25f);

		device.action().transition_to_fixedwing();

		// Wait a little before the transition back to multicopter,

Implement transition to fw as an action. #150

Implement transition to fw as an action. #150

Conversation

xgerrmann commented Nov 3, 2017 • edited by hamishwillee Loading

julianoes left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

coveralls commented Nov 3, 2017

julianoes commented Nov 3, 2017

julianoes commented Nov 3, 2017

hamishwillee commented Nov 5, 2017

xgerrmann commented Nov 5, 2017

julianoes commented Nov 6, 2017

julianoes commented Nov 6, 2017

julianoes left a comment

Choose a reason for hiding this comment

coveralls commented Nov 6, 2017

xgerrmann commented Nov 6, 2017

coveralls commented Nov 6, 2017

mrpollo commented Nov 6, 2017

mrpollo left a comment

Choose a reason for hiding this comment

coveralls commented Nov 6, 2017

xgerrmann commented Nov 6, 2017 • edited Loading

coveralls commented Nov 6, 2017

coveralls commented Nov 6, 2017

coveralls commented Nov 6, 2017

Choose a reason for hiding this comment

hamishwillee commented Nov 6, 2017

coveralls commented Nov 7, 2017

xgerrmann commented Nov 7, 2017 • edited Loading

coveralls commented Nov 7, 2017

Choose a reason for hiding this comment

xgerrmann Nov 8, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hamishwillee commented Nov 8, 2017

xgerrmann commented Nov 8, 2017 • edited Loading

julianoes commented Nov 8, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hamishwillee commented Nov 8, 2017

julianoes commented Nov 9, 2017

julianoes left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

coveralls commented Nov 10, 2017

xgerrmann commented Nov 10, 2017

coveralls commented Nov 10, 2017

coveralls commented Nov 10, 2017

coveralls commented Nov 10, 2017

coveralls commented Nov 10, 2017

coveralls commented Nov 10, 2017

Choose a reason for hiding this comment

coveralls commented Nov 13, 2017

mrpollo commented Nov 13, 2017

hamishwillee commented Nov 13, 2017

mrpollo left a comment

Choose a reason for hiding this comment

hamishwillee commented Nov 14, 2017 • edited Loading

Choose a reason for hiding this comment

xgerrmann commented Nov 3, 2017 •

edited by hamishwillee

Loading

xgerrmann commented Nov 6, 2017 •

edited

Loading

xgerrmann commented Nov 7, 2017 •

edited

Loading

xgerrmann Nov 8, 2017 •

edited

Loading

xgerrmann commented Nov 8, 2017 •

edited

Loading

hamishwillee commented Nov 14, 2017 •

edited

Loading