Raspberry PI 3 + OpenCV + Arduino UNO + ......(поледнее решение и вопрос в последнем сообщении)

Доброго времени суток!!!
Но опять двадцать пять!
Вот вид со стороны деталей (верхний слой но с низу остальные детали):


Помогите проверить размеры... Все источники (выше по теме) противоречивы. Шаг выводов колодок шилда 2.5 мм, а не как мне привычно 2.54.
Заранее благодарен!

Добавлено позже:
http://www.pselectro.ru/dvuhstoronnie_pechatnye_platy
Изготовление плат по их калькулятору плата 68x53мм двухсторонняя - слой меди 18 мкм с нанесением маски и маркировки на каждую сторону для:
10 шт - с НДС = 4859 руб
5 шт - с НДС = 4117 руб
1 шт - с НДС = 3524 руб
Вот и время настало... пора уже. Только размеры уточнить... точнее параметры и переразвести пока не поздно.

 

Наверное "была-не была" или авось?

 

Вот незадача:
заказал:

а приехал:

И на какой ляд он мне, у меня ARM-ов как блох у собаки, а тут ещё урод андроид... и за чем??? хоть бы DEBIAN(ну или UBUNTU на худой конец предоставили). Вот тебе и АЛИ!?!?!?

 

Выходит зря я плохо думал о Китайских Товарищах... После их рекомендации подключить и проверить тип (а надо срочно и HDMI переходник-удлинитель в комплект поставки не входил) стал думать как это сделать без промедлений. Вспомнил, что куму дарил подобное устройство с Android вместе со шнурком. Вот у него и подключил. Выходит мне прислали T02(что заказывал), а не A02 для которого был мануал в коробке. Искренне извиняюсь! (Наверное там у них загрузка такая большая, что мануалы путают). Внешне A02 и T02 не отличаются.

 

Доброго времени суток!
Вот пока заказ платы отложил... но дошли руки до приехавшего из китая MB1242:
mb1242.pdf
Поковырялся... поковырялся... отчаялся и решил подключить его не на ардуину, а на малину... да и так оперативнее (i2c на малине простаивает). Отказался от всех известных библиотек, потому как запутался (да и времени нет). А сделал свои примитивы на Си. Ну всё вместе с тестом в проекте:
mb1242.zip
Не ругайте сильно. Всё работает с устройством по адресу 0x70 по умолчанию.
Ну в принципе можно прикручивать к проекту... хотя может я что-то забыл.
Спасибо.

 

Доброго времени суток!
Собственно вопрос (плату пока не заказал):
- каким образом Вы определяете "точность" работы сонара. Я имел ввиду:

А именно не могу определиться с "угловой" точностью. Таким образом для каждого удаления свой угол захвата... т.е. "пятно" на каждом расстоянии своё. В моём случае данный сонар находится на поворотном устройстве рядом с камерой. Одним словом мне практически известно угловое направление камеры и сонара (если верить точности сервомашин). По этим параметрам предполагается строить карту пространства. Следует ли учитывать угловую "точность" по диаграмме направленности сонара, исходя из того, что для каждой дистанции свой радиус от центра углового направления (сонара с камерой). Пытаюсь осознать до конца то, что показано на прилагаемой картинке. Может есть у кого опыт в применении сонаров.
Как пример (исходя из картинки - питание 5 в и диаграмме C): для дистанции 150 см радиус менее 60 см, т.е. всё что попало в удаление от цента является объектом. Для 210 см это уже практически точка. Одним словом не могу понять по каким диаграммам работать и ориентироваться с целью коррекции.
Вот то что получилось закрепить вместе с камерой:

Понимаю, что криво... но для опытов всё-таки можно.
Предполагается учитывать диаграмму для программной коррекции.

Заранее благодарен за ответ!

 

Вот такая вот беда: ставил AQemulator на малину ранее и всё улетело. Имеется в виду проект darkbot ну и соответственно и qdarkbot. Их делал в среде Raspbian. Если бы не сонар о котором ранее упомянул и не вспомнил бы. Повезло, что выкладывал тут... скачал же их... хотя они и начало. Но возможно это и к лучшему. Заодно и со сборкой поработал:

Код (Text):

        Описание конфигуратора "config.sh"

        Для формирования проекта "darkbot" и дальнейшей компиляции. Все данные из директрории "src" копируются файлы в директорию "work".
    В директории "src" кроме исходников находится файл "config.h" в котором опрежделяются все параметры для компиляции. Скриптом "config.sh"
    производится изменение ряда параметров, которые в дальнейшем повлияют на ход компиляции. Крме этого скрипт копирует не все исходные файлы,
    а только определённые в интерактивном режиме работы.

        Запуск скрипта с ключём "--help" выведет соответствующую подсказку.
       
        Запуск с ключём "-ic" позволит запуститься скрипту в интерактивном режиме:
        1) произойдёт копирование "обязательных" файлов из "src" в "work":
            tdef.h        - типовые определения для проекта (заголовочный)
              config.h    - параметры конфигурации и компиляции (заголовочный)
              id.h        - средства идентификации (заголовочный)
              id.cpp        - средства идентификации
              vcsocket.h    - средства связи по сети (заголовочный)
              vcsocket.cpp     - средства связи по сети
        эти файлы присутствуют во всех конфигурациях.
        2) "use main function ( 1-main / 0-for extern )".
        Ответ "1" - означает, что данная программа будет запускаема. И будут скопированы файлы:
            main.h        - основной поток (заголовочный)
                main.cpp    - основной поток
        Ответ "0" - означает, что будет сформирован проект для применения внешними средствами разработки. Например QtCreator, тоесть файлы
        предназначаются для включения их в другой проект. Файл "Makefile" при этом формироваться не будет, как и скрипт запуска.
        3) "use wem cam ( 1-web cam / 0-No cam )"
        Ответ "1" - означает, что программа будет использовать ВЭБ-камеру. И будут скопированны файлы:
            wcam.h        - средства для ВЭБ камеры (заголовочный)
                wcam.cpp    - средства для ВЭБ камеры
        Ответ "0" - означает, что камера не используется как источник видео.
        4) "use local Motors ( 1-Morors / 0-No Motors )"
        Ответ "1" - означает, что программа будет применять средсва управления приводами (моторами и сервомашинами) и будут скопированыъ
        файлы:
            motors.h    - средства управления приводами (заголовочный)
                motors.cpp    - средства управления приводами
        Всё управление приводами производится через Arduino UNO R3 по последовательному интерфейсу с применением протокола
        Modbus RTU.
        5) "use local Modbus RTU ( 1-Local Modbus RTU / 0-No Local Modbus RTU)"
        Ответ "1" - означает, что программа применяет протокол Modbus RTU (это несколько противоречит пункту 4, который требует его -
        - недработка) и будут скопированны файлы:
            mrtu.h        - средства работы по Modbus RTU (заголовочный)
                mrtu.cpp    - средства работы по Modbus RTU
        6) "debug mode (use debug to console) ( 1-Message to console / 0-No message )"
        Ответ "1" позволит произвести компиляцию после которой программа будет выводить в консоль ряд отладочной информации.
        7) "client or server ( 1-client / 0-server )"
        Ответ "1" означает, что программа будет являться клиентским приложением (требует соединения с сервером)
        Ответ "0" означает, что программа является сервером.
        8) Далее происходит модификация файла "config.h" с выводом отчёта:

            ############################################
            #           Configutate Proeсt             #
            ############################################

            Debug message: 1
            Web Camera: 1
            Motorc control: 1

        9) Далее происходит формирование "Makefile" с запросом имени файла результата

            ############################################
            # Makefile Version: 01.03   Date: 22.04.2017
            ############################################

            interactive config:
            Name Project:

        Как раз этим именем и будет названа программа, если в П 2 выбран режим "use main function ( 1-main / 0-for extern )".

        10) "Using OpenCV:(1/0)" Применение библиотеки OpenCV. Фактически это требуется для ВЕБ камеры
        (П 3 - "use wem cam ( 1-web cam / 0-No cam )") и для работы с видео.
        11) Формирование скрипта запуска откомпилированной программы:

            ##############################################
            # Creating Strt Script
            ##############################################

            Name for Start. Script of BASH

        Производится запрос имени скрипта и порта прослушивания если это будет сервером (П 7 "client or server ( 1-client / 0-server )"),
        либо IP адрес и порт для соединения с сервером.

        После данной операции дтректория "work" копируется в устройство Raspberry и компилируется командой make. Запуск производится
        стартом скрипта (название формируется в П 11) в той же директории.


       

Таким образом можно будет формировать "заготовки" как для "конечных точек" коими будут клиенты и серверы. А так же заготовки для qdarkbot, что в QtCreator. Конечно вопрос с платой питания (ранее) и болезненный, но продвижка всё же есть. Ещё на вопрос по диаграмме направленности для сонара и можно идти далее в аппаратном смысле.

 

Прошу прощения я выложил "qdarkbot" а надо "darkbot" (первое для QtCreator, а не то что написано. Простите:
darkbot.zip
Ещё раз простите... тут работа - остальное производные от них. Пока не прикрутил сонар... потому ка не получил ответы на ранее заданный вопрос о диаграмме направленности, а сам я туплю-простите. Тест сонара (простой) выложен ранее.

 

Вот пыхтел, ждал ответа... и:
mb12xx.zip
Фактически диаграмму направленности моего MB1242 не определил пока, но реализовал возможность проверить её. Опытным путём конечно... как-то вбил диаграммы, те что в документации. График мелкий очень для применения... но кое-что. Смысл в том, что имея углы направления сонара, и дистанцию от него "знать" радиус ошибки от углового направления ("пятна отражения"). Собственно для алгоритма построения карты пространства пригодно. Ну понятно, что WEB камера вместе с OpenCV в довесок. Опыты продолжаются. Только ранее упомянутую схему надо прикрутить.

 

Вполне может кому это интересно... вот только не припомню говорил я про разделяемую память, что удобно, или нет. Позволит это производить обмен данными между разными программами через ОЗУ. Ранее я это делал только через сокеты... ну или файл в RAM диске. Но не так давно стал применять и это. Ну допустим какая-то некоторая программа формирует данные (допустим сонар по I2C), другая с GUI ну к примеру в среде QtCreator читает эти данные с выводом в GUI и модифицирует.
Вот сформировал (заголовочный):

Код (C++):

#ifndef _shared_mem_h_
#define _shared_mem_h_

#include <semaphore.h>
#include <fcntl.h>

//имя семафора в /dev/shm
#ifndef SEMAPHORE_NAME
#define SEMAPHORE_NAME "/test_named_semaphore"
#endif

//имя файла памяти в /dev/shm
#ifndef SHARED_MEMORY_OBJECT_NAME
#define SHARED_MEMORY_OBJECT_NAME "test_shared_memory"
#endif

//размер файла памяти
#ifndef SHARED_MEMORY_OBJECT_SIZE
#define SHARED_MEMORY_OBJECT_SIZE 32
#endif

//память - создание
extern int    Create_SHM(void);
//обмен с памятью
extern int     RdWr_SHM(void * mrd,        //ссылка на переменную для чтения
            u_int8_t * amrd,     //адрес на память
            u_int32_t szmrd,     //размер
            void * mwr,         //ссылка на переменную для записи
            u_int8_t * amwr,     //адрес на память
            u_int32_t szmwr);    //размер

extern int    Unlink_SHM(void);

#endif
 

Ну и исполняемая часть (заготовка к применению):

Код (C++):

//shared_mem.c
/*
    16.05.2017
*/
#include <unistd.h>
#include <sys/types.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <semaphore.h>
#include <fcntl.h>
#include <stdio.h>
#include <string.h>

#include "shared_mem.h"

sem_t     *sem;
int     shm;

//память - создание
int    Create_SHM(void)
{
    //память - создание
    if ( (shm = shm_open(SHARED_MEMORY_OBJECT_NAME, O_CREAT|O_RDWR, S_IRWXO|S_IRWXG|S_IRWXU)) == -1 )
            return -1;
    if ( ftruncate(shm, SHARED_MEMORY_OBJECT_SIZE+1) == -1 )
        return -2;
    //семафор - создание
    if ( (sem = sem_open(SEMAPHORE_NAME, O_CREAT, 0777, 0)) == SEM_FAILED )
        return -3;
    sem_post(sem);
    return 0;
}

//обмен с памятью
int     RdWr_SHM(void * mrd,        //ссылка на переменную для чтения
        u_int8_t * amrd,     //адрес на память
        u_int32_t szmrd,     //размер
        void * mwr,         //ссылка на переменную для записи
        u_int8_t * amwr,     //адрес на память
        u_int32_t szmwr)    //размер
{
    u_int8_t    *addr;
    sem_wait(sem);
    addr = mmap(0, SHARED_MEMORY_OBJECT_SIZE+1, PROT_WRITE|PROT_READ, MAP_SHARED, shm, 0);
    //проверка границ
    if(((u_int32_t)(addr) + SHARED_MEMORY_OBJECT_SIZE+1) < ((u_int32_t)(addr) + (u_int32_t)(amrd) + szmrd))    //адрес на память выше предела (чтение)
    {
        sem_post(sem);
        return -1;
    }
    if(((u_int32_t)(addr) + SHARED_MEMORY_OBJECT_SIZE+1) < ((u_int32_t)(addr) + (u_int32_t)(amwr) + szmwr))    //адрес на память выше предела (запись)
    {
        sem_post(sem);
        return -2;
    }
    if(szmrd > 0)
        memcpy(mrd, (void*)((u_int32_t)(addr) + (u_int32_t)(amrd)), szmrd);
    if(szmwr > 0)
        memcpy((void*)((u_int32_t)(addr) + (u_int32_t)(amwr)), mwr, szmwr);
    sem_post(sem);
    return 0;
}

int    Unlink_SHM(void)
{
    shm_unlink(SHARED_MEMORY_OBJECT_NAME);
    return 0;
}
 

Соответственно происходит формирование в /dev/shm файлы семафора... ну и файла памяти соответственно. Их имена и параметры определены в заголовочном файле.
Одним словом применяя эти куски в разных программах и работающих одновременно можно организовать обмен данными практически напрямую. Всё это для Linux. Как в винде не интересовался.

для компиляции потребуется ключ -lrt
вот Makefile для примера:

Код (Bash):

###########################
# Simple Generic Makefile #
###########################

#CC=terminal-gcc

CC=gcc

#PREFIXPATH=/usr/local/arm-linux/bin
#CC=$(PREFIXPATH)/arm-linux-gcc

#STRIP=$(PREFIXPATH)/arm-linux-strip
#NAME=proxy


CFLAGS=-c -Wall
LDFLAGS=-lpthread -lrt

#SOURCES=*.c
SOURCES=$(shell ls *.c)

OBJECTS=$(SOURCES:.c=.o)
EXECUTABLE=master_shm

all: $(SOURCES) $(EXECUTABLE)

$(EXECUTABLE): $(OBJECTS)
    $(CC) $(LDFLAGS) $(OBJECTS) -o $@

.c.o:
    $(CC) $(CFLAGS) $< -o $@

install:
    install -m 0755 $(EXECUTABLE) $(HOME)/local/bin

clean:
    rm -rf *o $(EXECUTABLE)
 

 

Доброго времени суток!
Вот подготавливаю. Правда есть много и не понятного. А именно:
- Показание сонара мы получаем;
- Направление угловое поворотного механизма по горизонтали и вертикали мы задаём сервомашинам. (Следует отметить, что точность... ну сами понимаете). Принято что ось X горизонтальной плоскости направлена вперёд по направлению самого устройства. Ось Z вертикальной плоскости направлена вверх. Соответственно ось Y направлена влево. Ну и соответственно поворот влево - инкремент угла по горизонтали и наоборот. Подъём камеры инкремент угла по вертикали и наоборот. За нулевое положение камеры и сонара принято как вперёд параллельно горизонтали. Одним словом это нулевая точка.
- Про диаграмму направленности спрашивал ранее.
Для определения положения точки в трёхмерном пространстве применил:

Код (C++):

//определение координаты точки по углу
int    gXYZ(    int    gH,    //относительный угол направления по горизонтали
        int    gV,    //относительный угол направления по вертикали
        int    dH,    //дистанция
        int    *X,    //координата на плоскости X
        int    *Y,    //координата на плоскости Y
        int    *Z    //координата на плоскости Z
        )
{
    //
    *X = (int)((float)(dH) * sin(M_PI * (float)(90 - gH) / 180.0));
    *Y = (int)((float)(dH) * sin(M_PI * (float)(gH) / 180.0));
    *Z = (int)((float)(dH) * sin(M_PI * (float)(gV) / 180.0));
    //
    return 0;
}

Почему так? Потому, что обрабатывать должен "кластер" из нескольких Raspberry, а не DirectX и т.п. для PC.
Хотелось бы увидеть от Вас замечания... может надо так-то по другому?. Да и заполнение не по "точке", а по "пятну" исходя из диаграммы направленности. Это тоже хотелось бы знать... может излишне и работать по точке?

Так же потребуется для переноса на "плоскость отображения"... ну это не столько для вывода на экран вместе с камерой, сколько для анализа и сопоставления с видео. Тоже пока не понятно к сожалению.

Заранее Спасибо!

 

Похоже не видеть мне поправок или замечаний. Сейчас делается функция (на Си) для отображения на плоскости (для теста). Именно с условиями:
- мы находимся в центре пространства. Точнее массива X * Y * Z и направление нашей камеры с сонаром понятны (мы задаём угол). По определению для теста :
(config.h):

Код (C++):

//размер
#define _szx    500
#define _szy    500
#define _szz    500

Наш сонар (позднее и OpenCV с камерой должны "синхронизировать" эти значения) "записывает" так называемые точки в этот массив (понятно, что с учётом угла разворота и подъёма). Но в данном случае опыта делаются две программы - одна просто в gcc (просто с текстом и Makefile), а другая для отображения в GUI(QtCretor) приложении. Собственно для этого и применяется разделяемая память(может и потом пригодиться, но для кластера только сокет). Первая программа формирует этот массив (случайных точек), а вторая программа выводит это на экран . Но... с учётом угла поворота (отображения). Понятное дело в функции есть и угол направления (по горизонтали и вертикали). И соответственно из центра массива (ну скажем 3D) и производится "осмотр" случайно сгенерированНых точек в этом массиве первой программой. Так вот я и надеюсь на подсказку в реализации функции вывода "области" пространства на "плоскость отображения" для GUI.(В QtCreator есть уже готовые рещения... но работать будет в конце концов не он в работе - а это только "модель"). Понятно что и пропорции соблюдать надо. Но (заготовка):

Код (C++):

//отображение на плоскости(экране)
int    gmapScreen(
        int        gH,    //относительный угол направления по горизонтали
        int        gV,    //относительный угол направления по вертикали
        int        Dg,    //угол обзора
        int        szH,    //размер по горизонтали отобрадения
        int        szV,    //размер по вертикали отображения
        u_int8_t    *scr    //массив для отображения (соответственно размерам szH и szV)  
        )

Да кстати всё в предыдущем сообщении взято из теоремы синусов(для треугольников ... в моём случае прямоугольный и длина гипотенузы это измеренная/заданная дистанция,допустим от сонара и она соответствует углу 90, при этом синус равен 1, что соответствует просто дистанции....
проверял тупо калькулятором на листе бумаги)). Но может есть что поумнее и побыстрее?
С Нетерпением жду помощи (подсказок, критики и т.п.)
С Глубоким Уважением!
Заранее Спасибо!

 

Кстати... у меня усы тоже в горизонтали... картинку надеюсь видите!
Но Я не бот, а живой! И Советы мне нужны в отличии от многознайки про эфироны!

Но вполне возможна тема не интересна по причине отсутствия "пыли" в глазах... и кроме картинок и видео уже давно никому не интересно. И круче ООП ничего не катит. Возможно!
Ну тогда простите.

 

Вот это вИНДА. Хоть и держу её в виртуальной машине и не выхожу в интернет с неё. Была она подключена к локальной сети (в режиме "Сетевой мост") в момент выхода в интернет из реальной машины (Debian)... система (WinXP виртуальная) возьми и обвались. Сколько себе клялся не выходи в инет при включенной винде... ну или хотябы её сетевое соединение отключай. А вот попал так попал. И рабочие файлы проекта PCad и библиотеки ушли в небытие. Дубль системы конечно есть, но рабочих данных уже нет !!!!! Хорошо, хоть коды не под виндой.

 

Могу ошибаться, но опыт подсказывает, что проблема скорее всего не в 'вИНДЕ'. Хотя может и в 'вИНДЕ', но не в Windows (будь то XP, Vista, 7 etc.).

 

Рефлекс Ctrl+S после каждого мелкого телодвижения? Автосохранение? Файлы на проброшеной с хоста ФС? Версионирование (Git/Mercurial, etc)? Бэкапы базы VCS?

 

p.s. вы бы в дюймовую систему сразу перешли и все непонятки по размерам исчезли бы, т.к. координаты стали бы целые и ясные, а не странные и дробные. Шаг 0.1inch=100mil, дефект правой колодки 10mil, дефект ICSP разъема 5mil от 50(25)mil сетки.

 

Да нет... Вы не так поняли! Виртуальный диск "осыпался" проблема с загрузкой системы и вообще файловая система на виртуальном диске (пытался на той же машине старт с реальных(разрешал привод CD) и виртуальных(образ ISO) CD дисков) . Я держу несколько виртуальных машин... у каждой свой виртуальный диск. Есть и резервный виртуальный диск с установленной ОС. Ну это чтобы не создавать чистый диск для новой виртуальной машины и не ставить на него ОС. Как правило диски делаю не большими... каждая машина только на несколько программ. Имел опыт со Step 7, Visual Studio и CodeSys на одной машине... и случались не очень редкие конфликты в софте... особенно со стороны Step 7, точнее с расширением (добавлением) для него. Потому и машины разные. Хочу заметить, что тот же косяк возникает и на реальном ноутбуке с Win XP... то регистрация осыпется... то ещё что.

 

Я и так учитываю 2.54 мм... а там где 2.5 мм я брал из источников в интернете. И данные в них противоречивы. Потому и задавал этот вопрос про размеры.

 

Перепроверю! Спасибо!
Хорошо, что заготовка размеров в PCB сохранилась в расшаренной директории /home/shared_users. Надо было там и делать всё. Хотя может поставить P-Cad под Wine. Просмотрщик (P-Cad Viewer) вроде, как работает без проблем.