- Mar 09, 2019
-
-
Anthony Lamping authored
-
Daniel Agar authored
-
mcsauder authored
Migrate a few more var initializations from the Mavlink class constructor list to the respective declarations.
-
mcsauder authored
Whitespace formatting in mavlink_main.cpp/h and begin work of some variable initialization at declaration in mavlink_main.h.
-
Daniel Agar authored
-
Anthony Lamping authored
-
mcsauder authored
Delete unnecessary #includes from mavlink_main.cpp and relocate a few #defines to mavlink_main.h for future variable initialization work.
-
dlwalter authored
-
- Mar 08, 2019
-
-
Beat Küng authored
-
Beat Küng authored
The effect was that threads that tried to exit were unnecessarily kept running. This did not cause problems except for increased resource usage.
-
Beat Küng authored
This solves a potential dead-lock when trying to shutdown: a call to exit() stops all threads and calls all destructors for static objects. The destructor of LockstepScheduler takes a lock. However this is not safe, as the lock could already be taken (by any thread).
-
Daniel Agar authored
-
- Mar 07, 2019
-
-
mcsauder authored
Add const specifier to remaining methods utilizing mavlink_message_t and similar message pointer types.
-
mcsauder authored
-
mcsauder authored
Cut case MAVLINK_MSG_ID_VISION_POSITION_ESTIMATE content and paste into handle_message_vision_position_estimate() method. Add const specifier to publish_odometry_topic() method.
-
mcsauder authored
-
mcsauder authored
-
mcsauder authored
-
mcsauder authored
-
- Mar 06, 2019
-
-
Daniel Agar authored
- jMAVSim in PX4/Firmware (a97151fe): https://github.com/PX4/jMAVSim/commit/0c25b7c18990a64fc851cfd7fe3aac9a4060aea3 - jMAVSim current upstream: https://github.com/PX4/jMAVSim/commit/8b2f4568e05935af57782fd0db9a434f733cc800 - Changes: https://github.com/PX4/jMAVSim/compare/0c25b7c18990a64fc851cfd7fe3aac9a4060aea3...8b2f4568e05935af57782fd0db9a434f733cc800 8b2f456 2019-02-28 Julian Oes - Merge pull request #95 from PX4/shell-style 3d0174a 2019-02-27 Matthias Grob - Fix shell script style
-
Daniel Agar authored
- mavlink v2.0 in PX4/Firmware (1a2b88ea30ae3bec38d2e9f11793042d7582506a): https://github.com/mavlink/c_library_v2/commit/f073569b746b6533c1715b0bbfed6c988444b257 - mavlink v2.0 current upstream: https://github.com/mavlink/c_library_v2/commit/2a47f11e73eef6d817af7934692b1223d7fb434f - Changes: https://github.com/mavlink/c_library_v2/compare/f073569b746b6533c1715b0bbfed6c988444b257...2a47f11e73eef6d817af7934692b1223d7fb434f 2a47f11 2019-03-01 PX4BuildBot - autogenerated headers for rev https://github.com/mavlink/mavlink/tree/747c3e73e9ad28e8011cdc5c98faf56752b1d32a
-
Daniel Agar authored
-
- Mar 05, 2019
-
-
mcsauder authored
-
mcsauder authored
Refactor set_publish() logic so that a default false value is not (re)set each loop in simulator_mapvlink.cpp and provide a default argument to set_publish() in simulator.h.
-
mcsauder authored
Create Simulator::set_publish() method and Simulator::_publish member variable to allow redefinition of the Simulator::handle_message() prototype to match MavlinkReceiver::handle_message().
-
Daniel Agar authored
-
Paul Riseborough authored
-
Paul Riseborough authored
-
Paul Riseborough authored
-
- Mar 04, 2019
-
-
Hamish Willee authored
-
Daniel Agar authored
- fixes #11317
-
- Mar 03, 2019
-
-
Gabriel Moreno authored
The simulator had hardcoded component ID and system ID (sysID was 0), ignoring what was set up in the params MAV_SYS_ID and MAV_COMP_ID. This caused an issue with multi-vehicle simulations that that rely on sysID to identify the vehicles. Signed-off-by:
Gabriel Moreno <gabrielm@cs.cmu.edu>
-
Morten Fyhn Amundsen authored
In CONTRIBUTING.md, the current link to the coding style leads to a 404 error. I've replaced it with a link to the Source Code Management part of the developer documentation, which is where the style guide seems to be now.
-
mcsauder authored
-
- Mar 02, 2019
-
-
mcsauder authored
-
mcsauder authored
-
David Sidrane authored
This reverts commit 0df34af1.
-
David Sidrane authored
-
David Sidrane authored
The cause of the stack detection fault is because of the level of nesting in the start up script. We need to determine the worst case configuration and set the bar there. This fault occurred some 42 calls deep due to script calling script (repeat). The HW stack check requires as a margin of 204 bytes. That is ISR HW stacking of CPU(8) FPU(18) registers and SW stacking of CPU(11) and FPU(16) registers. Total CPU(19) registers is 68 bytes and the total FPU(34) registers is 136 bytes. On a system with a separate ISR stack This only needs to be 104 so there is 100 bytes of headroom. But as coded the detection will give a false positive detection and fault. This does not mean that the stack will be corrupted. Adjustments to that stack can have no effect due to rounding. A stack size of 2608 and 2616 can yield the exact same size stack. So even when the failure is due to a 4 byte overflow, it can take greater than a 16 bytes increase to fix it. Because the final stack size is calculated with an 8 byte alignment after a 4 byte decrease. So 2624 becomes 2620 at runtime and will boot with SYS_AUTOSTART=4001.
-
Daniel Agar authored
- support range based for loops - add remove() method to remove a node - add clear() to empty entire list and delete nodes - add empty() helper
-