Open AndriyPt opened 6 years ago
In case of remote robot operation, it would be worthy to add and use (simulate) some proximity sensor (rather, ultrasonic) for force stopping (by low level instructions) of the robot at safe distance from an obstacle ahead. Later, the dependence of this distance on the robot's absolute velocity and also ability to change this distance remotely (in resonable limits, for jam resolving) can be implemented.
Not sure that I got the idea correctly, but it seems that it may be taken into account when using some obstacle avoidance algorithm. I guess we can use the Dynamic Window Approach or Follow The Gap. In this case, we can control the safe distance to obstacles and take into account the maximum speed.
@LyubomyrD navigation stack has this functionality. Although we might add extra safety feature such as bumper to detect collision and stop robot or perform other recovery actions.
@AndriyPt I agree about the Navigation stack - we will use algorithms from there, of course.
I also agree concerning the Navigation stack. But, I don't know how fast those algorithms are? So, how about some unexpected, fast moving obstacles (humans, animals)? Maybe, bumper is a good idea, but, imho, ultrasonic "bumper" is better.
So, do I understand you correctly @Ihoreg that the question is if we should install US distance sensors additionally to cameras which can be also used to locate objects and obstacles using AI recognition algorithms? My thinking is that these sensors are cheap, so why not.
One of the issues I had with these US sensors in my home project is that they don't detect the heaps of clothes in my room as the wave travels through such material and fades inside it. So, I was going to pair them with UV Sharp distance sensor, which in it's turn doesn't work well in very bright surroundings or for sources of light (that's what the manufacturer claims). Also, the US sensors cannot detect flat surfaces (such as wall) located at acute angles to the receiver. We can overcome this limitation using a set of sensors. But in most cases they worked fine for me.
Просто якшо буде нормальний лідар за 350 баксів, про який говорив Андрій, то питання в цих датчиках може відпасти ....
@SystemDiagnosticss А ми справді можемо таке поставити? Я, схоже, пропустив це. Якщо так, то я обома руками за. Інакше треба визначати що для нас є оптимальним за співвідношенням ціна/якість.
LIDAR за 350 то низька цінова категорія і відповідна нижча роздільна здатність. Проте він інтегрований із ROS і в принципі гарний старт. Відео можна побачити тут https://www.youtube.com/watch?v=pCF7P7u8pDk Сенсори можемо додавати по ходу, навігаційний стек має можливість поєднувати дані із багатьох сенсорів. Можна будувати аварійну зупинку абсолютно незалежно від навігаційного стеку і т.д., але то все по ходу ускладнення проекту :) Краще зробити щось просте із відносно невеликим бюджетом, потім буде легше знайти підтримку для складніших проектів ;)
Погоджуюсь з Андрієм, що для старту можна обійтися мінімальною функціональністю. Але по-ходу треба думати, що ми хочемо закласти в перший варіант повнофункціональної моделі (функції, устаткування, сенсори і т.п.) з точки зору дизайну (механічної конструкції). Тобто, якщо ми потім захочемо, щоб робот мав 10 pcs головних достоїнств (функцій), то мовинні подумати, куди вчепити сітку з я..., пардон, з сенсорами :) . Бо в тих прототипах дизайнів, що на даний момент запропоновані, я для них місця не побачив. Оскільки залізяку робити не так уже й дешево, то треба відразу пердбачити в конструкції можливості для апгрейду. Напевно, в цьому і є сенс таких дискусій про функціонал на даному етапі.
@ihoreg погоджуюсь. Потрібно добре продумати, що ми хочемо закласти в першій моделі, шоь в 2 гій моделі не довелося всі деталі робити/закупляти по новому.
@Ihoreg i @SystemDiagnosticss у цьому і краса симуляції робота, що можна доволі дешево побачити робота вживу. Механічний дизайн справа не проста і з першого разу зробити ідеально не вийде, тому, як на мене, варто зробити простий дизайн і довішувати до нього все, що можна. Коли ми побачимо, що немає де вішати, або корпус блокує сенсори і т.п. переробимо CAD і URDF. Так пройде кілька ітерацій, далі людина чи люди, які будуть робити робота додать ще свої корективи :) Ну і звичайно маєте рацію, фізичного робота треба робити із запасом на майбутнє, щоб можна було щось десь довішати і доставити (в розумних межах). Але для того треба почати експерементувати із чимось простішим у симуляції, щоб набратися досвіду :)
@AndriyPt супер.
А, тоді тим краще, що ми можемо собі такий дозволити.
У мене є кілька питань.
Як ви вважаєте, чи це на теперішньому етапі актуально, чи краще вирішувати по ходу проекту?
@MaxZhaloba завжди буде або мертва зона або умови за яких сенсори не працюють (освітлення, поверхні, температура), треба поексперементувати із позицією LIDAR, загалом його ставлять спереду, щоб "бачити" куди їхати. Можна купити за кілька тисяч LIDAR який повертає не площину, а хмару точок із простору, можна використати стерео-камери для карти простору і уникнення перешкод. Загалом намагаються використовувати кілька сенсорів. Будемо експерементувати на цьому етапі, поставимо десь LIDAR і запустимо симуляцію і будемо давати задачі проїхатися із різним типом перешкод і побачимо скільки буде помилок і чи варто додавати чи переміщати сенсори.
Create simulation of the robot with the following features:
Product implementation milestones