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

uORB add bitset for faster orb_exists check and remove uORB::Subscription lazy subscribe hack/optimization #14106

Merged
merged 10 commits into from
Mar 11, 2020

Conversation

dagar
Copy link
Member

@dagar dagar commented Feb 5, 2020

One of the inefficiencies in legacy orb_subscribe() addressed by the new uORB::Subscription was that attempting to subscribe to a topic would create the underlying device node (the orb topic publication). As a result we had several kilobytes worth of unused orb device nodes in many setups.

In uORB::Subscription we avoid this by checking if the publication actually exists (equivalent to orb_exists()), however each orb_exists() call is relatively expensive. The short term optimization was to throttle the calls within uORB::Subscription after an initial 1000 attempts. The potential problem with this is a subscription might miss initial updates to topics that are only published late in flight.

This PR makes those orb existence checks cheap enough we can use them in every single iteration by adding a bitset of atomic integers to the uORB DeviceMaster. Then I updated the orb generation to also create a class enum for ORB_IDs so that we have an index to use with the bitset.

Master (sensor_accel 0, 1, 2 exist, but 3 and 4 do not)

orb_exists sensor_accel 0: 100 events, 983us elapsed, 9.83us avg, min 9us max 10us 0.377us rms
orb_exists sensor_accel 1: 100 events, 1424us elapsed, 14.24us avg, min 14us max 15us 0.429us rms
orb_exists sensor_accel 2: 100 events, 2031us elapsed, 20.31us avg, min 20us max 21us 0.464us rms
orb_exists sensor_accel 3: 100 events, 3373us elapsed, 33.73us avg, min 33us max 34us 0.446us rms
orb_exists sensor_accel 4: 100 events, 95us elapsed, 0.95us avg, min 1us max 1us 0.219us rms

PR

orb_exists sensor_accel 0: 100 events, 968us elapsed, 9.68us avg, min 9us max 10us 0.468us rms
orb_exists sensor_accel 1: 100 events, 1408us elapsed, 14.08us avg, min 14us max 15us 0.272us rms
orb_exists sensor_accel 2: 100 events, 2027us elapsed, 20.27us avg, min 20us max 21us 0.446us rms
orb_exists sensor_accel 3: 100 events, 161us elapsed, 1.61us avg, min 1us max 2us 0.490us rms
orb_exists sensor_accel 4: 100 events, 95us elapsed, 0.95us avg, min 1us max 1us 0.219us rms
orb_exists sensor_accel 5: 100 events, 89us elapsed, 0.89us avg, min 1us max 1us 0.314us rms
orb_exists sensor_accel 6: 100 events, 81us elapsed, 0.81us avg, min 1us max 1us 0.394us rms
orb_exists sensor_accel 7: 100 events, 90us elapsed, 0.90us avg, min 1us max 1us 0.301us rms
orb_exists sensor_accel 8: 100 events, 90us elapsed, 0.90us avg, min 0us max 1us 0.301us rms
orb_exists sensor_accel 9: 100 events, 91us elapsed, 0.91us avg, min 1us max 1us 0.287us rms
orb_exists sensor_accel 10: 100 events, 91us elapsed, 0.91us avg, min 0us max 1us 0.287us rms

In master orb_exists() for a topic that doesn't exist (with valid instance) is quite expensive because you have to search the entire list of topics. On fmu-v3 configured as a multicopter that's 33.73 us (average). With this PR that same check is 1.61 us. That might seem small, but it adds up across hundreds or even thousands of calls per second.

Overall this saves a little bit of cpu (although quite a lot during the first 5-10 seconds of bootup) and a little bit of memory, despite increasing the size of the orb_metadata struct. More importantly it removes the possibility of subtle unexpected orb update behavior later in flight.

@dagar
Copy link
Member Author

dagar commented Feb 5, 2020

@julianoes @bkueng There's a bit more to do here to fix the RTPS build, but could you give this an initial pass? There are cleaner things we could do here if we're willing to drop C support, but I'll save that discussion for another day. I also have some ideas to build off of this for the next round of improvements towards the ultimate goal of uORB type and memory safety.

@bkueng
Copy link
Member

bkueng commented Feb 11, 2020

Looks good from a first look at it - I'll still need to go through the details.

@dagar
Copy link
Member Author

dagar commented Feb 13, 2020

TODO (in a followup PR later): store orb field names in a separate structure so that they can be GC'd in stripped down configurations that don't use logger or reply (eg CAN nodes #14148).

@PX4 PX4 deleted a comment from codecov bot Feb 13, 2020
@PX4 PX4 deleted a comment from codecov bot Feb 13, 2020
@dagar dagar changed the title [WIP] uORB add bitset for faster orb_exists check and remove uORB::Subscription lazy subscribe hack/optimization uORB add bitset for faster orb_exists check and remove uORB::Subscription lazy subscribe hack/optimization Feb 13, 2020
@dagar dagar marked this pull request as ready for review February 13, 2020 20:39
@dagar dagar requested review from bkueng and julianoes February 13, 2020 20:40
@dagar dagar added this to the Release v1.11.0 milestone Feb 13, 2020
@dagar
Copy link
Member Author

dagar commented Feb 13, 2020

The bitsets and testing were plucked from #11318.

 - add PX4 bitset and atomic_bitset with testing
 - add uORB::Subscription constructor to take ORB_ID enum
 - move orb test messages into msg/
@dagar dagar requested a review from a team February 13, 2020 21:05
Copy link
Member

@bkueng bkueng left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you check the difference in boot time?

*/
extern const struct orb_metadata *const *orb_get_topics() __EXPORT;

enum class ORB_ID : uint8_t {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Won't this cause troubles with the ORB_ID macro? At the least it will be confusing.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can get away with it because of the parentheses, but I'm not sure how questionable it is. The idea is make them equivalent and interchangeable in most uORB usage and possibly transition entirely to the enum class version later.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we were ready/willing to drop orb C support entirely we could actually get rid of the ORB_ID macro as a wrapper for orb meta pointer (eg __orb_vehicle_status) and replace it with a single byte enum class end-to-end.

Then ORB_ID(vehicle_status) would simply give you ORB_ID::vehicle_status.

@dagar
Copy link
Member Author

dagar commented Feb 17, 2020

Did you check the difference in boot time?

Not accurately, but I wouldn't expect it to be noticeably different. What will be noticeable is the cpu usage is significantly lower immediately after boot compared to current master where it's hammering orb_exists heavily for the first 10-20 seconds.

@dannyfpv
Copy link

dannyfpv commented Feb 17, 2020

Tested on Pixhawk 4 v5

Flight Card 1

Modes Tested:
Position Mode: Good.
Altitude Mode: Good.
Stabilized Mode: Good.

Procedure:
Arm and Take off in position mode, after flying for approximately one minute, switched to altitude then stabilized mode.

Notes:
No issues were noted, good flight in general.

Logs: https://review.px4.io/plot_app?log=e5f7fa23-0cc0-49bc-9579-1b8fc35eae76

Flight Card 2

Modes Tested
Mission Plan Mode (Automated): Good.
RTL (Return To Land): Good.

Procedure

Armed form QGC.
Took-off on mission plan mode
. Note that commands were sent form QGC (Armed and takeoff)
Once all waypoint completed vehicle switched to RTL and landed as expected.
Good flight in general.
Note:
No issues were noted, good flight in general.

Logs: https://review.px4.io/plot_app?log=d5245655-61d1-4a77-8120-b701c7f18793

Flight Card 3
Modes Tested
Position Mode: Good.
Mission Plan Mode (Automated): Good.
RTL (Return To Land): Good.

Procedure
Arm and Take off in position mode, after flying for approximately one minute, switched to mission plan mode then make sure that vehicle follows all waypoints as shown in QGC, once completed all waypoint
Good flight in general.

Note:
No issues were noted, good flight in general.

Logs:

https://review.px4.io/plot_app?log=2b4c8524-f89c-4555-ad09-148ded67a646

Flight Card 4
Modes Tested
Fail safe:The radio control turned off and the vehicle returned and landed correctly.
Tested good.

Logs:
https://review.px4.io/plot_app?log=5c4d7813-da17-45db-9204-be2c6fdf220b

@jorge789
Copy link

jorge789 commented Feb 17, 2020

Tested on PixRacer V4

Flight Card 1

Modes Tested:
Position Mode: Good.
Altitude Mode: Good.
Stabilized Mode: Good.

Procedure:
Arm and Take off in position mode, after flying for approximately one minute, switched to altitude then stabilized mode.

Notes:
No issues were noted, good flight in general.

Logs: https://review.px4.io/plot_app?log=1266da62-77c8-4240-92e2-f252f816b4a4

Flight Card 2

Modes Tested
Mission Plan Mode (Automated): Good.
RTL (Return To Land): Good.

Procedure

Armed form QGC.
Took-off on mission plan mode
. Note that commands were sent form QGC (Armed and takeoff)
Once all waypoint completed vehicle switched to RTL and landed as expected.
Note:
No issues were noted, good flight in general.

Logs: https://review.px4.io/plot_app?log=e342b6a8-836d-4c27-9429-bd3c0e35ca10

Flight Card 3

Modes Tested
Position Mode: Good.
Mission Plan Mode (Automated): Good.
RTL (Return To Land): Good.

Procedure
Arm and Take off in position mode, after flying for approximately one minute, switched to mission plan mode then make sure that vehicle follows all waypoints as shown in QGC,once completed all waypoint then swith RTL.
Note:
No issues were noted, good flight in general.

Logs: https://review.px4.io/plot_app?log=249c19a1-aee7-4aad-90b5-c8188bf15de1

Flight Card 4

- Modes Tested
Position Mode: Good.
Failsafe RTL (Return To Land): Not returning after RC shutdown.
- Procedure
Arm and take off in position mode, after flying approximately a few seconds, turned off the RC to activate the fail-safe RTL, wait for the vehicle to return and land.
- Notes
No issue noted, good flight in general.

Logs: https://review.px4.io/plot_app?log=9a17acc3-27d2-419a-aa04-a8824f4e06b8

Tested on CUAV nano V5

Flight Card 1

Modes Tested:
Position Mode: Good.
Altitude Mode: Good.
Stabilized Mode: Good.

Procedure:
Arm and Take off in position mode, after flying for approximately one minute, switched to altitude then stabilized mode.

Notes:
No issues were noted, good flight in general.

Logs: https://review.px4.io/plot_app?log=501bba47-295e-41da-87e6-3d125338b5ff

Flight Card 2

Modes Tested
Mission Plan Mode (Automated): Good.
RTL (Return To Land): Good.

Procedure

Armed form QGC.
Took-off on mission plan mode
. Note that commands were sent form QGC (Armed and takeoff)
Once all waypoint completed vehicle switched to RTL and landed as expected.
Note:
No issues were noted, good flight in general.

Logs: https://review.px4.io/plot_app?log=7a20f475-00d0-4d68-9b37-e62116082a20

Flight Card 3

Modes Tested
Position Mode: Good.
Mission Plan Mode (Automated): Good.
RTL (Return To Land): Good.

Procedure
Arm and Take off in position mode, after flying for approximately one minute, switched to mission plan mode then make sure that vehicle follows all waypoints as shown in QGC,once completed all waypoint then swith RTL.
Note:
No issues were noted, good flight in general.

Logs: https://review.px4.io/plot_app?log=9387a417-3dce-4a3a-83f9-9354b7f4ee53

Flight Card 4

- Modes Tested
Position Mode: Good.
Failsafe RTL (Return To Land): Not returning after RC shutdown.
- Procedure
Arm and take off in position mode, after flying approximately a few seconds, turned off the RC to activate the fail-safe RTL, wait for the vehicle to return and land.
- Notes
No issue noted, good flight in general.

Logs: https://review.px4.io/plot_app?log=590db8a9-a5ea-491b-a0d3-5b169d487ea0

Tested on NXP V3

Flight Card 1

Modes Tested:
Position Mode: Good.
Altitude Mode: Good.
Stabilized Mode: Good.

Procedure:
Arm and Take off in position mode, after flying for approximately one minute, switched to altitude then stabilized mode.

Notes:
No issues were noted, good flight in general.

Logs: https://review.px4.io/plot_app?log=16dd32ef-2f40-47dc-8b68-516c61d239be

Flight Card 2

Modes Tested
Mission Plan Mode (Automated): Good.
RTL (Return To Land): Good.

Procedure

Armed form QGC.
Took-off on mission plan mode
. Note that commands were sent form QGC (Armed and takeoff)
Once all waypoint completed vehicle switched to RTL and landed as expected.
Note:
No issues were noted, good flight in general.

Logs: https://review.px4.io/plot_app?log=675540ad-aba5-4f77-b4b2-deca6c5b9606

Flight Card 3

Modes Tested
Position Mode: Good.
Mission Plan Mode (Automated): Good.
RTL (Return To Land): Good.

Procedure
Arm and Take off in position mode, after flying for approximately one minute, switched to mission plan mode then make sure that vehicle follows all waypoints as shown in QGC,once completed all waypoint then swith RTL.
Note:
No issues were noted, good flight in general.

Logs: https://review.px4.io/plot_app?log=97d4e29a-ba21-4b11-a476-0f3fb791251c

Flight Card 4

- Modes Tested
Position Mode: Good.
Failsafe RTL (Return To Land): Not returning after RC shutdown.
- Procedure
Arm and take off in position mode, after flying approximately a few seconds, turned off the RC to activate the fail-safe RTL, wait for the vehicle to return and land.
- Notes
No issue noted, good flight in general.

Logs: https://review.px4.io/plot_app?log=36d829a1-da6e-416c-9a82-edd433879ca1

@dagar dagar requested a review from bkueng February 20, 2020 01:36
@dagar
Copy link
Member Author

dagar commented Mar 10, 2020

Any other feedback?

Copy link
Member

@bkueng bkueng left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good to go from my side.

Copy link
Contributor

@julianoes julianoes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome! 🎉

@dagar
Copy link
Member Author

dagar commented Mar 11, 2020

Thanks everyone.

@mrpollo
Copy link
Contributor

mrpollo commented Mar 13, 2020

🎉 thanks @dagar

lgtm

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants