for Robot Artificial Inteligence
카메라에서 바라보는 Coordinate는 Optical Coordinate이다.
우리의 object는 로봇이기 때문에 카메라로 우리가 보고 있는 Pointcloud들은 로봇 Coordinate로 변환을 시켜줘야 한다.
변환 하는 방법은 아래와 같다.
R = 0 0 1
-1 0 0
0 -1 0
q = 0.5, -0.5, 0.5, -0.5
하나하나 대입을 하면 Coordinate 변환을 알 수 있다
Robot Base link를 고려하기 않고 camera link로만 어떤 작업을 할 때 많이 사용 한다. (로봇 베이스를 통해 세계를 바라 보고 싶다면, extrict parameter만 고려해주면 된다.)
관련 테스트는
https://www.andre-gaschler.com/rotationconverter/
으로 로테이션 확인을 할 수 있다.
이전에는 아니 딥러닝을 통해서 Model을 만들고, 임베디드 시스템에 들어오는 raw데이터를 받아서 Out를 끌고 오는데, 왜 Computation Cost를 고려해야하는지 이해가 가지 않았다.
그러나 최근에 알게되었다.
당연히 train data와 valid data로 train을 하면서 Model을 만드는 것은 오랜 시간이 걸린다. 그러니 그래픽카드를 써서라도 최대한 빨리 모델을 하려고 한다.
그리고 얻어진 모델을 이용하여서 embedded system에서 사용이 되는데, 이는 Model의 Network 사이즈와 수에 비례해서 Computation cost가 올라간다.
즉 network를 lite하게 네트워크 짜는 것도 중요하다. 그래야 real-time으로 사용할 수 있다.
RSLIDAR사용 할때 IP를 맞춰야 한다. 맞출 떄 Ubuntu -> Setting -> Network가서 연결 상태를 확인하고, ip를 확인하여서 rslidar sdk에 IP를 수정을 해주면 된다.
Rearsense camera로 마찬가지이다. 여기에 +로 쓸만한 launch는 rdgd.launch파일이 있는데 이것이 포인트클라우드로 변환을 시켜주는데, 엄청 편하다.
아래 방법으로 Catkin_ignore을 통해서 워크스페이스 내에 필요없는 페키지 컴파일을 생략할 수 있다.
https://answers.ros.org/question/208180/how-to-use-catkin_ignore-file-correctly/
켈리브레인션을 할때 손으로 대충 Transformation matrix를 맞춰줘야 하는데, 이때 자주 사용하고 확인 할 수 있는 방법은 static tf publisher(http://wiki.ros.org/tf#static_transform_publisher)이다. 혹은 내가 만든 icp_calibration_pkg를 이용하여서 할 수 있다.(base와 sensor link의 transformation matrix을 손으로 대충 만들고, 우리는 base 좌표계로 pointcloud를 보고 싶기때문에, 구해진 T 행렬을 inverse를 해서 pointcloud에 적용을 하면, base 좌표계로 pointcloud를 알 수 있다.)
이와 같은 방식으로 projection을 할 수 있다. 즉 base 좌표 뿐만 아니라, 월드 좌표로까지 pointcloud를 프로젝션을 하여서 global map에도 표현을 할 수 있다. 즉 너무 쉽당. transformation matrix inverse를 잘해서 base link 나 work coordinate 표현, 혹은 sensor 좌표계로 tranformation matrix를 통핸 투영으로 표현을 하기도 쉽다.
로켓챗, 레드마인, Gitlab
파트장, 팀장님 리포터, 나머지 분들 Developer
MPS(megabytes per second) 초당 점유하는 메가바이트(램 점유율 확인)
Vector Maps both provide accurate metric information likewise Occupancy Grid Maps, and represent data as a graph that can be processed for path planning and maps merging as efficiently as with topological maps.(https://www.researchgate.net/publication/305804235_Vector_Maps_A_Lightweight_and_Accurate_Map_Format_for_Multi-robot_Systems)
적정 로봇 센서 업데이트 및 프로세스 이후 주기는 30hz(imu 400hz, camera 60hz, lidar 5Hz/10Hz/20Hz)
코어 600% 중에 30% 사용. 즉, 코어 6개(CPU) 중에 연산량을 얼마나 잡아 먹는지.(30%) 잡아먹음.
https://itblogpro.tistory.com/52
우리가 개발한 로봇은 모두 완벽할 수없다. 다만 우리가 만든 테스트 셋 중에서는 완벽해야 된다.
센서를 고르거나 테스트할 때 컴웨어 버전도 고려하자.
데이터셋을 많이 뽑아서 자리에서 테스트 하자.
TOF -> CAN -> CAN_BRIDGE_ -> 제어기 -> 젯슨나노
R&R (Role and Responsibilities)
offine mapping
g3log는 백그라운드로 돌리면서 log를 취득하는 방법이다. 프리 라이센스로 google에서 만든 glog보다 속도가 더 빠르다고도 한다.
자세한 사용 설명은 아래에 나와 있다.
http://www.yangguanjun.com/2017/10/19/g3log-introduction/
https://awesomeopensource.com/project/KjellKod/g3log
An example project integration of g3log, both statially and dynamically built can be found at g3log_example_integration
https://github.com/KjellKod/g3sinks
To avoid race conditions(여러 쓰레드에서 동시에 한 instant를 쓰는데 문제가 되는 것) explicit calls to the sink will return a std::future.
Other calls, through the LOG API are more of asynchronous nature
경쟁 조건을 피하기 위해 싱크에 대한 명시적 호출은 std::future를 반환합니다.
LOG API를 통한 다른 호출은 비동기에 가깝습니다.
https://github.com/KjellKod/g3log/blob/master/src/g3log/sinkhandle.hpp
https://github.com/KjellKod/g3sinks
If you want logging files per function or per module then you would have to write that logging sink yourself.
If you feel that it’s a good contribution, please consider adding it to the community’s contribution of sinks, which can be found at
https://github.com/KjellKod/g3sinks
You can start with an extending sink, either the default here or some at g3sinks. Writing a sink is really simple - see the docs for it
https://www.codeproject.com/Articles/809893/G-log-asynchronous-logging-the-easy-way
주로 보면 좋은 것이 g3sinks/examples/logrotate_main.cpp 이다.
즉 메카니즘은
addsink를 이용해서 하면 된다.
이떄 rotate log(로그 파일 데이터량을 한정하여 여러 파일로 쪼개서 할 수있다.)로 쪼갤 수 있기도 하고 log filter아웃을 이용하여서 따로 저장할 수 있다.
완전 좋은 기능!!!
한번 해보기를 추천한다!
Log rotation : 영어에서 번역됨-정보 기술에서 로그 회전은 로그 파일이 너무 오래되거나 너무 크면 압축, 이동, 이름 변경 또는 삭제되는 시스템 관리에 사용되는 자동화된 프로세스입니다. 새로운 수신 로그 데이터는 새로운 새 파일로 전달됩니다.
std::future<std::string> log_file_name = handle->call(&g3::FileSink::fileName);
handle의 File name을 콜해서 log_file_name에 덮어 씌우는 것이다.
std::future는 동기화 결과를 얻을때 사용된다.