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

Adjust robot speed by a estimated distancefactor. #311

Merged
merged 12 commits into from
Mar 4, 2023

Conversation

reger24
Copy link
Contributor

@reger24 reger24 commented Nov 28, 2022

Adjust robot speed (in object tracking mode) by a distance factor estimated from the width of the tracking box
assuming that the tracking box is lage if close to tracked object and apply the factor to the speed control vars.

#310

The distancefactor is estimated from width of the tracking box, assuming that the tracking box is lage if close to tracked object and apply the factor to the speed control vars.
@thias15 thias15 added this to In progress in OpenBot via automation Nov 29, 2022
@thias15
Copy link
Collaborator

thias15 commented Nov 29, 2022

Hi @reger24. Thanks for your contribution. Using only the width of the bounding box may be quite specific to the object of choice and the orientation of the phone. For example the ratio between bounding box width and frame width would be quite different if the phone is in landscape or portrait mode and also very different if you track a person vs. a car. I think it would probably be better to use the area (width*height) instead.

@thias15
Copy link
Collaborator

thias15 commented Nov 29, 2022

Also, the style check did not pass. You can fix the style by navigating to the android folder and then executing ./gradlew applyStyle

@reger24
Copy link
Contributor Author

reger24 commented Nov 29, 2022

Hi @thias15 , your point with the orientation dependency is very likely true (as I tested & concentrated on landscape).
I'll try your suggestion using the area and update my proposal/pull-request.
Thanks & Tschüß

@thias15
Copy link
Collaborator

thias15 commented Nov 30, 2022

@reger24 sounds good. You can just push updates to your branch and the PR will be updated automatically.

@reger24
Copy link
Contributor Author

reger24 commented Nov 30, 2022

fyi: both, the current (box-width) and the suggested (box-area) adjustment work best in landscape mode, not so well in portrait mode, but in landscape I find it relative nice/ok.
So for now, I still would go ahead and fine-tune the box-area solution (if you prefer, could be deactivated in portrait).

…k box area in relation to screen area, assuming that the tracking box is lage if close to tracked object/person and apply the factor to the speed control vars.

Below a threshold the robot will stop, above a threshold robot will follow with predefined (UI) speed.
Restriction: as it works best if phone is in landscape mode, the robot will only use the stop threshold in portrait but not adjust speed.
applyStyle made tow (grrr) changes
@reger24
Copy link
Contributor Author

reger24 commented Dec 1, 2022

Hi @thias15 , 18effda is the final change to the 1st implementation of it (if you choose so).
cu

@thias15
Copy link
Collaborator

thias15 commented Feb 13, 2023

Hi @reger24. Sorry for the delay, very busy few months. This looks good, but since it does not work reliably in portrait mode for some classes, how about making this scaling optional? There could be a on/off for dynamic speed; its setting could be stored in the shared prefs. What do you think?

@reger24
Copy link
Contributor Author

reger24 commented Feb 13, 2023

Hi @reger24.
There could be a on/off for dynamic speed; its setting could be stored in the shared prefs. What do you think?

@thias15 sounds good to me (with shared pefs switch), I'll update the pr in the next days.

…fault to false)

- implemented getter/setter for class SharedPreferencesManager
- added a "Option" descrition to readme.md
reduce screenshot size
@thias15
Copy link
Collaborator

thias15 commented Feb 23, 2023

Sorry for being so picky. But ideally the dynamic speed toggle would be only in the ObjectNav GUI since it's specific to that. The settings menu is meant more for global settings like permissions, video streaming mode, robot connection, etc.

@reger24
Copy link
Contributor Author

reger24 commented Feb 24, 2023

No problem (was not completley convinced myself about the best place of the option switch), for now I'll try to squeeze it to ObjectNav's bottom sheet - and update PR.

P.S.
BUT
I believe sooner or later it would be benefitial to have a separate settings/preference screen for such option settings (which go into/are stored in openbot_settings.xml) as I foresee some more to come, to make them visible/adjustable (as preference w/o overcrowding bottomsheets) .
So I intend to prepare a separate PR

  • with a "Advanced (AI) Settings" or "Detail AI Setting" which make parts of openbot_settings.xml visible
  • add a Link to the "Settings" which opens the Advanced Settings screen, with categories for "General (all AI screens)" (eg. CAMERA_SWITCH) and individual (eg. "Object Tracking") for related settings.
    • later (if there are more options)... a button on bottomsheet could also open the Advanced Settings screen

OpenBot automation moved this from In progress to In review Mar 4, 2023
@thias15 thias15 merged commit 777aadb into isl-org:master Mar 4, 2023
OpenBot automation moved this from In review to Done Mar 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
OpenBot
  
Done
Development

Successfully merging this pull request may close these issues.

None yet

2 participants