While the config_sitl_rcS_dir is used more extensively (and actually
only depending on the base cmake target), the variables
config_sitl_viewer and config_sitl_debugger are just used to be
passed on for the run_config target; config_sitl_debugger is even
*always* 'disable'. Hence, they don't really need to be cached
(INTERNAL or not). Before this patch FILEPATH was used instead
of INTERNAL, but I doubt very much that that was intended. That
only makes sense when cmake-gui would be used and then would pop-up
a file browser to let the user pick a file (while really they
need to pick a directory, so it's wrong either way).
The ONLY reason caching would be used is when a developer edits
the build_posix_sitl_*/CMakeCache.txt files, changes these values
and then runs cmake in the build directory again, now overriding
the values intended here. Nevertheless, I left in the caching.
The main change in this commit (that theoretically has no real effect)
is that I removed the duplicated maintenance of
posix_sitl_broadcast.cmake. When that file was added, it was an
exact copy of posix_sitl_default.cmake and is since not always
maintained to remain the same. I don't think that difference is
in anyway relevant for the broadcasting part though.
Note that I think that something like that also holds for the
posix_sitl_replay.cmake; it would be a lot better - maintenance-wise
- when it was just derived from (or the same as) posix_sitl_default,
I think.
* Low impact changes from path_cleanup branch.
This is a step towards minimizing the diff with path_cleanup branch.
* Update ecl.
* Revert matrix update.
* Revert ecl and matrix.
* Update sitl gazebo.
* Revert sitl_gazebo and matrix changes.
This adds a new module that does:
- read an parse an ULog file, given via ENV variable 'replay'
- apply all parameters from the log file
- read and apply user-defined override parameters from a file
- publish all messages in 'real-time' from the log file and add a constant
offset to the timestamp to match the system time.
- apply changed parameters in the log (which are not overridden)
* Use DriverFramework as a PX4 module
Targets wanting to use DriverFramework must add
lib/DriverFramework/framework
to their config file.
Signed-off-by: Mark Charlebois <charlebm@gmail.com>
* Removed spurious code
No need to add if check before for loop
Signed-off-by: Mark Charlebois <charlebm@gmail.com>
* Added DriverFramework to NuttX configs
Added lib/DriverFramework/firmware to nuttx configs
Signed-off-by: Mark Charlebois <charlebm@gmail.com>
* Updated src/lib/DriverFramework
* Removed DF_TARGET and __DF_${OS} defines
These are now handled inside DriverFramework
Signed-off-by: Mark Charlebois <charlebm@gmail.com>
* Updated DriverFramework
Signed-off-by: Mark Charlebois <charlebm@gmail.com>
* Restored __DF_${OS}
The include files in DriverFramwork need to know the target OS.
Signed-off-by: Mark Charlebois <charlebm@gmail.com>
- Note that the simulator still uses gpssim by default
- now the gps module can be used in the SITL. this makes it possible to test
the real gps HW under POSIX
additional steps needed to use it:
- in the rcS_jmavsim_iris, make sure to start the gps instead of gpssim:
gps start -d /dev/ttyACM0 -s
- disable the mavlink serial connection in simulator_mavlink.cpp,
openUart(PIXHAWK_DEVICE, 115200);
- this also fixes a memory leak in the gps module
