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

SITL (x86) Target #8731

Merged
merged 23 commits into from
Mar 24, 2023
Merged

SITL (x86) Target #8731

merged 23 commits into from
Mar 24, 2023

Conversation

Scavanger
Copy link
Contributor

INAV on x86 Hardware.
Fully usable, at least for Wings. Copter support will be added later, the "Fake compass" is still missing.
The following simulators are supported:

  • X-Plane
  • RealFlight

Tested on Windows and Linux.

The usage is still a bit cumbersome, an integration into the configurator would be nice.
Extra offline tab with UI for command line options?

@MrD-RC
Copy link
Collaborator

MrD-RC commented Jan 24, 2023

F**king awesome!!! Thanks Andi!!!

@DzikuVx
Copy link
Member

DzikuVx commented Jan 24, 2023

Nice!

@DzikuVx DzikuVx added this to the 6.1 milestone Jan 24, 2023
@Scavanger
Copy link
Contributor Author

Can someone take a look at the "Github actions"?
They always fail, I can compile on my development machine without any problems, even with ninja.

@stronnag
Copy link
Collaborator

If I apply the .diff from your patchset locally, it fails in the same way as the CI:

In file included from /home/jrh/Projects/fc/inav/src/main/common/time.h:25,
                 from /home/jrh/Projects/fc/inav/src/main/build/debug.h:33,
                 from /home/jrh/Projects/fc/inav/src/main/fc/config.c:25:
/home/jrh/Projects/fc/inav/src/main/fc/config.c:115:18: error: 'SETTING_I2C_SPEED_DEFAULT' undeclared here (not in a function); did you mean 'SETTING_ACC_LPF_HZ_DEFAULT'?
  115 |     .i2c_speed = SETTING_I2C_SPEED_DEFAULT,
      |                  ^~~~~~~~~~~~~~~~~~~~~~~~~
/home/jrh/Projects/fc/inav/src/main/config/parameter_group.h:229:9: note: in definition of macro 'PG_RESET_TEMPLATE'
  229 |         __VA_ARGS__                                                     \
      |         ^~~~~~~~~~~
[142/293] Building C object src/main/t...s/WINGFC.elf.dir/__/__/fc/fc_msp.c.obj

@Scavanger
Copy link
Contributor Author

@stronnag
OK.
Issues found, now it works

@RomanLut
Copy link
Contributor

RomanLut commented Feb 4, 2023

I would propose to integrate this with INAV HITL plugin.

So usage scenario would be:

  1. Start SITL executable
  2. Start X-Plane, click "Connect to SITL" in X-Plane menu
  3. Flight using RC controller connected to PC via USB
    Thats all!

Then a lot of code from this submit will not be required (new fake sensors, direct X-Plane and Realflight communication, exernal OSD application). A lot of work has been done for HITL support/X-Plane plugin already; direct X-plane communication dublicates it.

The only requirement is to compile executable for x86 and expose UARTs as TCP ports. Executable should work as a Server, and X-Plane plugin/Reaflight app/whatever as Client. Server should not contain any X-Plane/RealFlight related code.

Communication will be done through single MSP connection (TCP port) using MSP_SIMULATOR command (like HITL does). Additionally X-Plane plugin would send MSP commands for Receiver Type: MSP, using values from RC controller connected to PC.

As for RealFlight support, it would be nice to have separate executable with GUI, which provide menu options similar to X-Plane plugin. As I understand, it is not possible to integrate neither additional menu options nor OSD into Realflight except Window overpainting.

@Scavanger
Copy link
Contributor Author

@RomanLut

Yes, SITL / HITL has some code duplications.

That's exactly what I thought at the beginning and wanted to handle the communication based on the HITL MSP command. But a big problem arose: The initialisation and the runtime calibration.
With HITL, the hardware sensors are used for this and then overwritten by the MSP command, since SITL cannot use hardware sensors, almost the entire initialisation would have to be carried out again, especially the position estimator is very sensitive (I had it so far that it worked via MSP, only the position estimator always flipped up and the nav modes never worked) and major changes would be necessary and SITL should not intervene greatly.
By the time the ports are initialised and MSP commands arrive, the whole thing has already run, so the whole communication must be up and running before the initialisation and runtime calibration takes place.

There are also more simulators that can be integrated: Flight Gear /JSBSim, Silent wings, Gazebo,...). A lot of code would have to be written twice.
I am currently working on an integration into the Configurator for the nice GUI. Only the external OSD programme has to stay, that exceeds the capabilities of Javascript.

@stronnag
Copy link
Collaborator

stronnag commented Mar 6, 2023

Well fsck me. Builds on gcc 12.2.1, working with configurator. So there was no compiler bug?
Anyway, kudos. Absolutely awesome job.

@stronnag
Copy link
Collaborator

stronnag commented Mar 6, 2023

Terminal 1:

$ ./inav_6.0.0_SITL
INAV 6.0.0 SITL
[SYSTEM] Init...
[SIM] No interface specified. Configurator only.
[EEPROM] Loaded 'eeprom.bin' (32768 of 32768 bytes)
[SOCKET] Bind TCP port 5760 to UART1
[SOCKET] Bind TCP port 5761 to UART2

Terminal 2:

$ nc  -4 localhost 5760 # SITL is v4 only
#

Entering CLI Mode, type 'exit' to return, or 'help'

# status
status
INAV/SITL 6.0.0 Mar  6 2023 / 19:33:49 (4083e107)
GCC-12.2.1 20230201
System Uptime: 68 seconds
Current Time: 2041-06-28T01:04:00.000+00:00
Voltage: 0.00V (1S battery - NOT PRESENT)
CPU Clock=500MHz, GYRO=FAKE, ACC=FAKE, BARO=FAKE, MAG=FAKE
Sensor status: GYRO=OK, ACC=OK, MAG=OK, BARO=OK, RANGEFINDER=NONE, OPFLOW=NONE, GPS=NONE
System load: 11, cycle time: 1001, PID rate: 999, RX rate: 9, System rate: 10
Arming disabled flags: CAL COMPASS ACC RX CLI

Terminal 1:

[SOCKET] 127.0.0.1 connected to UART1
Segmentation fault (core dumped)

@stronnag
Copy link
Collaborator

stronnag commented Mar 6, 2023

Then, (fcset is an mwptools program to restore saved settings):

# remove all _hardware = settings from the saved file

This can't possibly work ....

$ fcset -d tcp://127.0.0.1:5760  /tmp/MrFloaty_WINGFC_r168.txt 
2023-03-06T19:50:54+0000 Opening tcp://127.0.0.1:5760
2023-03-06T19:50:54+0000 Starting restore: /tmp/MrFloaty_WINGFC_r168.txt
2023-03-06T19:50:54+0000 Establishing CLI
[▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇] 100%
Error(s) in restore
	beeper -ON_USB
	serial 20 17 115200 115200 115200 115200
	set imu_acc_ignore_rate = 10
	set telemetry_halfduplex = OFF
	set smartport_fuel_unit = PERCENT
** Please check FC settings **
2023-03-06T19:50:59+0000 Rebooting (FC_MGR_STATE_EXIT)

Somewhat impressed. Opens just fine in the configurator. Nice, nice nice.

@stronnag
Copy link
Collaborator

stronnag commented Mar 6, 2023

btw. It would be really nice if the SITL could re-spawn itself on reboot.

@Scavanger
Copy link
Contributor Author

@stronnag
Thanks.
I was able to isolate the problem to a simple function call of constrain() in getAxisRcCommand().
As a workaround I implemented the constrain() logic direct, now it works:

nt16_t getAxisRcCommand(int16_t rawData, int16_t rate, int16_t deadband)
{
    int16_t stickDeflection = 0;

#if defined(SITL_BUILD) // Workaround due to strange bug in GCC > 10.2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108914   
    const int16_t value = rawData - PWM_RANGE_MIDDLE;
    if (value < -500) {
        stickDeflection = -500;
    } else if (value > 500) {
        stickDeflection = 500;
    } else {
        stickDeflection = value;
    }
#else
    stickDeflection = constrain(rawData - PWM_RANGE_MIDDLE, -500, 500);   
#endif
    
    stickDeflection = applyDeadbandRescaled(stickDeflection, deadband, -500, 500);
    return rcLookup(stickDeflection, rate);
}

No idea why GCC is hung up on it.

Segmentation fault error:
For me (WSL, Unbuntu 20.20, GCC 11.3) it works perfectly, are you sure your using the latest version?
I had the bug in the status command once, which occurred when no OSD was configured.

@stronnag
Copy link
Collaborator

stronnag commented Mar 6, 2023

For me (WSL, Unbuntu 20.20, GCC 11.3) it works perfectly, are you sure your using the latest version?

It was pulled from your repo about 30 minutes ago.

$ git log
commit 4083e1071979fecd444c25b7aef2ffa521cdb9a4 (HEAD -> SITL-CI-TEST, origin/SITL-CI-TEST, origin/HEAD)
Author: Andi Kanzler <andreas.kanzler@outlook.com>
Date:   Sun Mar 5 01:22:47 2023 -0300

    Update ci.yml

@Scavanger
Copy link
Contributor Author

btw. It would be really nice if the SITL could re-spawn itself on reboot.

Yup, I have set this in the Configurator integartion. I'm still waiting for feedback from the beta testers, then the PR for the configurator will come.

This is what it looks like: https://www.youtube.com/watch?v=VyIAI__GuAg

@Scavanger
Copy link
Contributor Author

$ git log
commit 4083e10 (HEAD -> SITL-CI-TEST, origin/SITL-CI-TEST, origin/HEAD)
Author: Andi Kanzler andreas.kanzler@outlook.com

Ah, there's the problem.
You are using SITL-CI-TEST, which is my test repro to test the Github actions, which is on an old version with the bug,
Use the SITL Branch, please: https://github.com/Scavanger/inav/tree/SITL

@stronnag
Copy link
Collaborator

stronnag commented Mar 6, 2023

btw. It would be really nice if the SITL could re-spawn itself on reboot.

Yup, I have set this in the Configurator integartion. I'm still waiting for feedback from the beta testers, then the PR for the configurator will come.

This is what it looks like: https://www.youtube.com/watch?v=VyIAI__GuAg

I was thinking more of reboot from CLI exit or MSP_REBOOT rather than involving the configurator. So the actual SITL recognosed reboot and respawned. Seems like this is an FC function.

@stronnag
Copy link
Collaborator

stronnag commented Mar 6, 2023

But more awesomeness ... this is so nearly a general implementation vice configurator / x-plane

Let's run it with mwp and load a pathologically testing WP mission ...

$ mwp -d tcp://127.0.0.1:5760
20:07:43.227580 /home/jrh/.local/bin/mwp  -d tcp://127.0.0.1:5760 --rings 50,20 --dont-maximise -S 8192 -t 8 
20:07:43.227761 buildinfo: 2023-03-06T11:43:07Z Linux 6.2.2-zen1-1-zen x86_64 eeyore
20:07:43.227770 toolinfo: gcc version 12.2.1 20230201 (GCC)  / GNU ld (GNU Binutils) 2.40 / Vala 0.56.4
20:07:43.227784 version: mwp c09ad001 (development) / 2023-03-05T16:59:07+00:00 6.064.610
20:07:43.227868 "Arch Linux" on eeyore running Linux 6.2.2-zen1-1-zen x86_64
20:07:43.227874 WM: XWayland / gnome
20:07:43.227888 GL: Intel / Mesa Intel(R) HD Graphics 4600 (HSW GT2)
20:07:43.233212 hypervisor: none
20:07:43.233276 GLib2 2.72
20:07:43.233294 MQTT enabled via the "paho" library
20:07:43.241053 Using fl2ltm 1.0.7 commit:cc0b298
20:07:43.277975 Using speech api 1 [espeak]
20:07:43.279481 Get map preference
20:07:43.611411 Starting Bing proxy 
20:07:43.920371 External proxy "gmproxy" listening on :39935
20:07:43.931529 External proxy "bproxy" listening on :46119
20:07:43.949971 BB load async map zoom : true
20:07:43.963528 Loaded /home/jrh/.config/mwp/vcols.css
20:07:43.965371 Fixed font true
20:07:43.974947 Delta speed 2.000000
20:07:43.992631 Show main window
20:07:44.061322 Enabled mag anomaly checking 45⁰, 3s
20:07:44.064228 Host power: 0%, state: Unknown (0), warn: None (1)
20:07:44.064246 mwp will manage power and screen saver / idle
20:07:46.972640 Try connect tcp://127.0.0.1:5760
20:07:46.972870 Connected tcp://127.0.0.1:5760 false
20:07:46.973235 Serial ready
20:07:46.973395 MSP Error: MSP_CMDS_IDENT[100] 
20:07:47.013809 Using MSP v2 0205
20:07:47.054749 Model name: "BenchyMcTesty"
20:07:47.095824 V2 mixer 8 0
20:07:47.218750 Feature Mask [10480896] : telemetry false, gps true, current true
20:07:47.344811 INAV v6.0.0  SITL (4083e107)
20:07:47.385943 Generate navconf 13 true
20:07:47.386030 Masks arm 1 angle 4 horz 8 ph 400 rth 800 wp 1000
20:07:47.467777 WP_GETINFO: 120/0/0
20:07:47.511760 Activeboxes 8 00800008 00000000
20:07:47.511795 Requesting common settings
20:07:47.511815 Request setting nav_wp_max_safe_distance
20:07:47.511826 Request setting inav_max_eph_epv
20:07:47.511833 Request setting gps_min_sats
20:07:47.554744 Received nav_wp_max_safe_distance 400m
20:07:47.597795 Received (raw) inav_max_eph_epv 1000
20:07:47.639769 Received gps_min_sats 6
20:07:47.680819 Arming flags: Calibrating,Navigation unsafe, • Fix quality, • 0 satellites, • 1st wp distance 400m,Compass cal,RC Link (41a00), load 12% MSP_CMDS_INAV_STATUS
20:07:47.700907 Initialised "espeak" for speech
20:07:47.701216 Sensors: Acc Baro Mag  (0087)
20:07:47.701265 INAV v6.0.0  SITL (4083e107) API 2.5 Nav Pr 0 «BenchyMcTesty»
20:07:47.701275 switch val == 00800008 (0000000c)
20:07:47.701287 message => No GPS detected
20:07:47.704651 no GPS, sensor = 0x87
20:07:47.704677 Timer cycle for 4 items, 25 => 97 bytes
20:07:47.704727 Start poller
20:07:55.905759 Arming flags: Calibrating,Navigation unsafe, • Fix quality, • 0 satellites, • 1st wp distance 400m,Compass cal,Hardware failure,RC Link (49a00), load 12% MSP_CMDS_INAV_STATUS
20:07:55.905804 sensor health 8087 1 0
20:07:55.905956 init icon 8 8 8 (false)
20:07:55.907833 request sensor info
20:07:55.948802 Sensor status 0
20:08:32.081772 WP_GETINFO: 120/120/1

image

@stronnag
Copy link
Collaborator

stronnag commented Mar 6, 2023

The crash looks like a firmware bug. Not even BATMAN INAV should reference a NULL pointer:

Thread 1 "inav_6.0.0_SITL" hit Breakpoint 1, cliStatus (
    cmdline=0x55555562c827 <cliBuffer+7> "")
    at /home/jrh/Projects/inav-sitl/src/main/fc/cli.c:3420
3420	    cliPrintf("%s [%u x %u]", osdDisplayPort->displayPortType, osdDisplayPort->cols, osdDisplayPort->rows);
(gdb) p osdDisplayPort
$1 = (displayPort_t *) 0x0

@Scavanger
Copy link
Contributor Author

@stronnag
I know. The problem is that this is actually microcontroller code and therefore there is no exit method and no cleanup, on the STM32 the code is also simply "choked" and restarted.
On the PC, the SITL process must be terminated and restarted, which must then be done by an external "watchdog" programme.

@stronnag
Copy link
Collaborator

stronnag commented Mar 6, 2023

@stronnag I know. The problem is that this is actually microcontroller code and therefore there is no exit method and no cleanup, on the STM32 the code is also simply "choked" and restarted. On the PC, the SITL process must be terminated and restarted, which must then be done by an external "watchdog" programme.

OK, I can wrap it in a while true shell script

@stronnag
Copy link
Collaborator

@stronnag I know. The problem is that this is actually microcontroller code and therefore there is no exit method and no cleanup, on the STM32 the code is also simply "choked" and restarted. On the PC, the SITL process must be terminated and restarted, which must then be done by an external "watchdog" programme.

OK, I can wrap it in a while true shell script

It's quiet possible to re-exec the SITL on reboot (rather than exit). Expect a PR soon with some other small stuff as well.

  • Fix BSD compilation
  • More canonical getopts usage
  • Allow host names & IPv6 for XPlane
  • Allow IPV6 on serial
  • Re-exec on firmware reboot

Some of which is to better support this little toy

@DzikuVx DzikuVx changed the base branch from master to release_6.1.0 March 14, 2023 20:31
@DzikuVx
Copy link
Member

DzikuVx commented Mar 23, 2023

@Scavanger please resolve conflicts

@DzikuVx DzikuVx merged commit 74cc4d8 into iNavFlight:release_6.1.0 Mar 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants