Simulation setup

The simulator can be built with a command like make sim_posix_revolution or make sim_osx_revolution (detailed instructions for the dependencies at OSX can be found at Setting-up-simulation-for-the-TauLabs-GCS-on-OSX. It is then deposited in build/sim_posix_revolution.elf and can be run. However, the revolution board that the simulator is mimicking starts with no configuration in flash, and how you set this up is a bit different from a normal flight board.

First it's necessary to configure GCS to use TCP for its telemetry session to the board. From the tools menu, select options and enter the item "IP Network Telemetry". Select "TCP connection" and port 9000, and hit apply.

Then you should be able to select "Connections: TCP: localhost" from the connections menu at the lower right and click connect. With luck, the RX bar will fill up with received telemetry.

The following are the steps of how I setup gcs and the board's config (theflash.bin) in order to run navigation:

• Set vehicle "multirotor", quad X, motor output channels 1-4
  apply / save
• tools - options - controller - "allow control of gcs receiver"
  apply / ok
• input, rc input, throttle type gcs channel 1 .. yaw type gcs channel 4
  apply / save
• input, flight mode switch settings, set number of flight modes to 1
• arm airframe using "yaw left" (this is what I prefer)
  apply / save
• go to map in flight data, right click on map, 'set home location'
• attitude, filter settings, attitude alg insoutdoor, navigation algorithm ins
  apply / save -- may cause a fpe.
• modules, enable vtol path follower, path planner, altitude hold
  apply / save
  disconnect
  restart simulator
  connect
• uavobject browser, VtolPathFollowerSettings - YawMode = path
• uavobject browser, VtolPathFollowerSettings - ThrottleControl = TRUE

Errata

1. Floating point exceptions in the Posix simulator. It seems some parts of the navigation and state estimation code are prone to divide by zero, underflow, and overflow. For now, I have edited the simulator as follows:

diff --git a/flight/PiOS.posix/posix/pios_sys.c b/flight/PiOS.posix/posix/pios_s
index 667d4a0..8f8863e 100644
--- a/flight/PiOS.posix/posix/pios_sys.c
+++ b/flight/PiOS.posix/posix/pios_sys.c
@@ -49,11 +49,13 @@ static void sigint_handler(int signum, siginfo_t *siginfo, v
        exit(0);
 }

+#if 0
 static void sigfpe_handler(int signum, siginfo_t *siginfo, void *ucontext)
 {
        printf("\nSIGFPE received.  OMG!  Math Bug!  Run again with gdb to find
        exit(0);
 }
+#endif

 void PIOS_SYS_Init(void)
 {
@@ -65,15 +67,15 @@ void PIOS_SYS_Init(void)
        int rc = sigaction(SIGINT, &sa_int, NULL);
        assert(rc == 0);

-       struct sigaction sa_fpe = {
-               .sa_sigaction = sigfpe_handler,
-               .sa_flags = SA_SIGINFO,
-       };
+       //struct sigaction sa_fpe = {
+//             .sa_sigaction = sigfpe_handler,
+//             .sa_flags = SA_SIGINFO,
+//     };

-       rc = sigaction(SIGFPE, &sa_fpe, NULL);
-       assert(rc == 0);
+       //rc = sigaction(SIGFPE, &sa_fpe, NULL);
+       //assert(rc == 0);

-       feenableexcept(FE_DIVBYZERO | FE_UNDERFLOW | FE_OVERFLOW | FE_INVALID);
+       //feenableexcept(FE_DIVBYZERO | FE_UNDERFLOW | FE_OVERFLOW | FE_INVALID)
 }

2. The quad's starting location relative to the home location seems random. This makes testing return to home tricky. I need to look into why this is.
3. If you ctrl-c the simulator or the simulator crashes while GCS is connected, it will be awhile before you can start it again, because of sockets in the TIME_WAIT state. I believe the simulator uses SO_REUSEADDR properly, but the gcs does not-- so if you are running these on the same host you hit this problem. I will fix this soon.
4. Using GCS means you can't really neutralize yaw or other sticks readily, so it's difficult to prevent the quad from spinning.
5. Actuators are always 1000 in scopes from what I can see-- would be nice to have real values.