-
Notifications
You must be signed in to change notification settings - Fork 12
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
Get Pat/FR-07 moving with OAK cone detection #985
Conversation
…mode and fixed FPS from config
VanJee and OAK camera changes are already in master, so now this PR could get slightly smaller ... I hope |
#name, x, y, width, height = b[:5] | ||
# new (temporary?) format | ||
w, h = image.get_size() | ||
a, b, c, d = frameNorm(h, h, detection[2]).tolist() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand these lines. What are "a, b, c, d"? Is it universal?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is ugly copy & paste from OAK demo code (abcd is mine) ... this code/format I still do not like, but hopefully somebody else will also need to display bounding boxes in lidarview and we will unify it
dist = selection[mask].min() / 1000 | ||
else: | ||
dist = 0.0 | ||
self.publish('obstacle', float(dist)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the float necessary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
float is needed in order not to propagate numpy structure. Or if you mean why not to use millimeters and int ... then yes, I would like fractional numbers more :)
@@ -0,0 +1,25 @@ | |||
""" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the future plan of this code? It seems like a one off.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you are right, that it is dependent on OAK-D default config of depth camera. This is like "ver0", which detects obstacle in front of the robot and typically next step is STOP, or slow down. I plan to use it on "robotem rovne" as fallback.
"links": [ | ||
["can.can", "platform.can"], | ||
["platform.can", "can.can"], | ||
["app.desired_speed", "platform.desired_steering"], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I dont like mixing of the desired_speed and desired_steering. Yes, it is not part of this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well, you are right - maybe we should add some module which will do transition from one to another?? (if possible)
This is development of Pat robot (go, follow path)
https://robotika.cz/robots/pat-a-mat/cs#240302
https://robotika.cz/articles/oak-d-pro/cs#240304
My bad, that they are interconnected now as preparation for "Cones Challenge 2024". I may actually revert some of the changes like gz-support.
There is also "obstacle detection 3D' in its "almost dummy" stage ... and also VanJee set/get IP utilities ... hmm