Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Bash scripting for posix #5162
This adds bash scripting for POSIX. The startup file is now evaluated by bash.
This PR adds the possibility to spawn PX4 modules out of bash. Basically,
Clients can run or spawn PX4 modules or commands by connecting to the
The main exe starts as a server and runs a startup script using bash. Each command in the startup script such as 'commander start' gets aliased with a prefix as 'px4-commander start' and symlinked to the px4 main executable.
Additionally, this allows commands to be sent from outside pxh, so from other terminals (on the same computer). All that is needed is to have the px4 exe and the symlinks in the PATH.
Thanks to @bkueng for the big help.
Progress to get this PR in
Future work after this PR
How to test
The normal SITL startup already uses the new unified SITL startup script rcS, it can get started with:
To send a command in another terminal window, adapt the PATH:
and send a command:
Or listen to a uORB message:
Press Ctrl+C to exit.
To test this on Snappy, just build and upload normally:
Open adb shell, and start it with:
Then choose, the airframe config using the param SYS_AUTOSTART and restart. The current options are:
Julian, this is a great solution!
One comment: The following lines should stay under "if param compare SYS_AUTOSTART 4100" since they're not been tested in other configurations.
qshell gps start -d /dev/tty-4
I think I'm probably late for this, but I was working on the current state of master branch and then I saw this PR. Quick question: why do you want to start the px4 components via arbitrary shell scripts? Wouldn't a declarative approach via configuration file (ini, json or other format) and then probably a single binary to control the internal parts be simpler?
Because it allows you to follow the UNIX system design of a collection of small apps and mixing calls to the system with calls to the PX4 middleware.
It's easy to support a JSON file format as well, but that would be rather for fixed vehicle configurations (which is important for products).
I suggest you try this PR when it's done - running the uORB listener in a separate she'll and watching different topics in parallel is an extremely powerful development tool.
referenced this pull request
Aug 15, 2016
It's certainly an improvement over the current one. However since the wrappers are actually talking to another daemon (the px4 binary) that responds accordingly, it's more a client/server approach than a classical "collection of small apps". In this case I usually see people using a declarative approach, i.e. a config file, because it avoids tempting hacks to add lots of sleeps here and there, scripting all the startup sequence. It's more or less a similar scenario of init implementation in which everybody went away from pure script init (be it systemd, upstart, android init, MacOS, etc) to a more declarative approach, even if in some of them still exists limited support for scripting.
@julianoes I'm closing this as stale. I would love to see this in by all means. But I think it would be good if you could break it down instead into one PR that adds the capability (but leaves the current startup scripts) and then iterate on breaking those down.
That should be much quicker and take much less of your time than re-architecting the complete startup of all targets.