Sunday, September 29, 2019

ESP-EYE 그리고 ESP32-CAM (세 번째 카메라 테스트)



약 2년전, Home Security를 위해 카메라 영상을 WIFI로 전송하는 장치를 구현하였다. (http://withthing.blogspot.com/2018/12/upgrade-home-cctv.html)

당시, ArduCAM이 촬영한 영상을 ESP8266가 받고, ESP8266으로 구현한 WebServer에 영상을 Streaming 혹은 Capture 영상을 보이도록 하였다. 여기에 MQTT로 Camera를 제어하기 위한 dashboard를 만들었다. (ESP8266은 내부망이기 때문에 port forwarding을 설정하였다.)

두 번째로는, 또 다른 카메라(ov7670)과 아두이노를 사용하여 PC에서 시리얼로 영상을 전송받아 출력하였다.
https://helloiot.wordpress.com/2017/08/02/ov7670-arduino-nano/



첫 번째 시도였던, ArduCAM+ESP8266 조합이 여러모로 쓸모가 있는데, 그것은 ESP8266이 WIFI는 기본이고 Arduino 대비 우월한 성능(속도, 메모리 등)으로 MCU의 역할을 수행하기 때문에 할 수 있는 일들이 많기 때문이다.  그래서 나는 언제부턴가 아두이노 보다 ESP를 더 많이 활용하고 있다.  다만 이 값 싸고 훌륭한 모듈이 중국에서 만들어졌다는것이 안타깝고...  아직 품질이나 안정성도 비교적 떨어진다.  그러나 수 많은 사람들이 이 모듈을 사용하기 시작하면서 framework가 많이 발전하였다.

그런 와중에 ESP에서 ESP-EYE 개발킷을 - 이들의 기존 제품가격 대비 - 싸지 않은 가격(2만원대)에 출시하였고, 이는 음성인식, 얼굴인식 기능까지 open source로 구현되는 상당히 호기심 가는 제품이기에 구매하여 테스트 해보았다.

비싼가격(?) 때문인지 패키징도 잘 되어있고, PCB보드도 기존과 다르게 상당히 신경쓴 모습을 볼 수 있었다.


Image result for esp-eye

펌웨어 소스코드는 오픈소스로 github에서 esp-who로 공개되어 있다. 이를 빌드 하기 위한 tool-chain은 역시 같은 곳에서 esp-idf로 공개되어 있다.

모든것을 준비하고 펌웨어를 성공적으로 빌드하고 전원을 넣고 실행을 하였다.
그리고 들뜬 마음으로 serial monitor를 보았더니...




카메라가 인식되지 않는다고 한다.

인터넷을 좀 찾아보니 카메라 연결문제, 설정문제, 전원문제 등 다양한 이야기들이 있었지만 좀처럼 해결되지 않았다.  카메라가 고장난것일까?

그래서 ESP-EYE의 카피버전? 정도로 생각되는 ESP32-CAM을 추가로 구해서 다시 실험을 하기로 했다. 이 제품은 aliexpress에서 저렴하게 구할 수 있고...  물론 배송은 한달이다.


역시 잊을만 하니 드디어 배송되었다. 하도 늦게 배송이 이루어지니 막상 물건이 오면, "이게 뭐였더라?" 할 때도 있다.


ESP32-CAM은 Arduino IDE에서 CameraWebServer 예제를 사용해볼 수 있다.
CameraWebServer는 'ESP32 Wrover Module' 보드의 예제이다.

ESP32 Wrover Module

주의: Partition Scheme: "디폴트" 가 아니라 "Huge APP (3MB No OTA)" 로 설정해야 함.
ESP32 Wrover Module은 추가보드 매니저에 다음을 추가 하여야 함: https://dl.espressif.com/dl/package_esp32_index.json


CameraWebServer 예제




펌웨어를 빌드하고 실행해 보았다. 역시... 한번에 되리라고는 기대도 안했다.

"Brownout detector was triggered"

위 메세지와 함께 무한부팅~!  씐난다!

보통 저 메세지는 전원이 딸리면 재부팅하는 경우의 메세지인데...
brownout detector를 off 해보았다. 그러나... 정상동작 하지 않았다. 당연히 전원이 부족해서 발생하는 트리거인데 이걸 끈다고 정상작동하겠냐..

원래 ESP8266은 고질적인 초기 전원문제가 있다. 이는 WIFI 때문으로 알려져있고... 이를 해결하기 위해 전원단에 capacitor를 추가하기도 한다.


ESP32-CAM의 연결도는 다음과 같다.




ESP-EYE와는 다르게 USB-TTL이 없으므로 외부의 USB-TTL 어뎁터를 사용해야 한다.
누군가는 이렇게 동작하니까 이 도식을 올렸을 터인데.  나의 경우 동작하지 않았다.
(인터넷을 찾아보면 많은 사람들이 나와 같은 문제를 겪는 것 같다.)


내가 잠깐 착각한 것이 있다.  USB-TTL이 전원 공급용이 아니라는 것을.
FTDI에도 물론 Power out이 있다. 그러나 이것은 logic ic에 전원을 공급하기 위한 용도일 뿐이라 그 전원은 어떤 서킷에는 충분하지 못할 것이다.

내가 가지고 있는 <FT232RL FTDI USB 3.3V 5.5V to TTL Serial Adapter Module> 모듈은 5V, 3.3V 출력이 가능하다.

나중에 ESP32-CAM의 전원사용량을 확인해 보니, 5V에서 약 210mA정도를 사용하였다.

처음에는 USB 허브 전원문제 인것 같았다. USB 2.0의 출력이 최대 900mA(단일 포트에서는 100mA인것 같은데.. 900mA는 여러 포트를 동원해야 하는 것인지? 잘 모름)라니까 문제가 없을 것 같기도 하고. 단일 포트에서 100mA라면 문제가 되는 상황이고. 하여튼 확실하지 않으니 허브에 외부전원(5V, 4A)을 (겨우 맞는것을 찾아) 연결하였다.

그럼 되야겠지?   하... 여전히 안된다. 하지만 이는 곧 이해가 되기 시작했다.

USB-TTL의 출력 자체가 딸리는 구나.

그래서 USB-TTL에 ESP32-CAM이 연결된 상태로 전력을 확인해보았다.

최대 70mA...    될리가 없지.

USB-TTL에 전원을 충분히 공급해주는것과 상관 없이 이놈의 출력 전원이 그정도 뿐이니 애당초 될리가 없는 것이다.

FT232RL datasheet를 찾아보았더니 내부 레귤레이터의 출력은 50mA가 최고란다.





5V로 dip switching하는 경우에는 regulator를 사용하지 않을 것 같아 테스트 해보았는데, 무조건 regulator를 통하는것 같다. 출력은 변함이 없었다.

USB-TTL adapter에 따라 전원 공급이 충분한 제품이 있을 수도 있을 것이다.

아무튼 이러한 상황이므로, 외부 전원을 ESP32-CAM에 직접 인가해 보았다.

짜짠~!




아, 쫌 기쁘다.  삽질 끝에 카메라 웹 서버가 잘 동작한다!


정리하면, USB-TTL adapter는 전원용이 아니라는 것.  ESP시리즈는 WIFI 땜시 전원을 많이 사용한다는 점!

따라서 ESP는 배터리 전원을 사용할 경우 WIFI 사용을 최소화 하고 sleep mode를 최대한 활용해야 하며, 가능하면 외부전원을 안정적으로 공급할 수 있어야 할 것이다.


이것의 발단이 된 ESP-EYE 보드는 여전히 안된다. 얘는 설계가 잘 되었는지 애초에 전원 문제는 없었다.

아닐 수도 있으나 카메라 자체의 문제도 살짝 의심되므로 카메라 모듈만 알리를 통해 추가 구매 하였다. 이 결과는 한달 후인 다음달에나 알 수 있을 것이다.



ESP 모듈의 활용도는 정말 많다. 소개하지 않았지만 이 안에는 다양한 센서가 있고 32비트 코이어며, 메모리도 많고 RF도 지원한다. 그것도 매우 저렴한 가격에!




공식적으로 세 번째 카메라 테스트 이지만, 사실 2.5번째 정도 되는 실험이 잠시 진행되었었다. 이것은 FIFO 버퍼가 없는 카메라 센서를 FPGA에 연결하여 VGA로 스트리밍 하는 목표였다. 하지만, FPGA는 그리 간단하지 않았고 DRAM을 다루는 부분부터 필자의 지식한계를 넘어서 나중으로 나중으로 미룬 상태이다.  이것에 관한 성과가 있게 되면 공유할 계획이다.









Thursday, September 5, 2019

Inside the IC


내가 가지고 있는 IC를 미니 현미경으로 확대해 보았다. 뭔가 구조가 보이긴 하네..

Wednesday, September 4, 2019

MQTT broker 서비스를 이사가다.

장치간의 메시징(통신)을 위해 MQTT - Message Queuing Telemetry Transport,  ISO standard (ISO/IEC PRF 20922) - 프로토콜을 사용하고 있고, 다음 그림과 같이 MQTT broker(or server)가 연결된 디바이스들(subscriber)의 mqtt에 기반한 메시징을 중계해준다.


Image from www.mathworks.com


알려진대로 매우 가벼운 프로토콜이기 때문에 IoT 디바이스들에 적용되기에 적합하다.

문제는 mqtt broker인데 이는 서버이므로 PC든 라즈베리 파이든 NAS든 broker를 구동할 서버가 준비되어야 한다. 여기에는 두가지 문제가 있는데, 하나는 간단한 응용을 위해 항시 켜져있는 서버를 운용해야 한다는 점과, 서버가 내부 IP 영역에 존재하면 그 외부의 장치들은 접근하기가 어렵다는 것이다. 물론, 전자의 경우 NAS같이 원래 항상 운용되는 장비가 있다면 거기에 mqtt broker를 설치/운용할 수 있으며, 후자의 경우 port forwarding 을 사용하여 내/외부 모두 접근이 가능한 서버를 구축할 수도 있을 것이다.
그런데 간단한 구축을 위해 너무 귀찮잖아!

이런 경우를 위해 유/무료로 mqtt broker 운용해주는 site들이 여럿 있다.

나같은 경우 CloudMQTT에서 제공하는 무료 서비스를 사용하고 있었다.
무료의 경우 생성할 수 있는 채널 수 등이 제한되어 있었는데, 그래도 충분히 활용할 만 했었다. 그런데, 오랜만에 새로운 채널을 생성하려고 했는데 이게 웬걸. 무료 정책이 바뀌어서 기존에 만든것은 유지하지만 새롭게 만들거나 변경하는것이 불가능했다. 뭔가 하려면 기존것을 상당부분 삭제해야 하는 상황이다!

[CloudMQTT 무료버전]

Cute Cat

  • 5 users/acl rules/connections
  • 10 Kbit/s

CloudMQTT 무료 서비스는 사용자수던, acl rule(채널)수던, 접속자 수던 5개로 제한되고 있고, 통신속도는 10 Kbit/s !  이거 너무하지 않은가?


그래서 다른 대안을 찾기 시작했고, broker로 유명한 mosquitto를 제공하는 재단에서 mqtt 테스트 서버를 무료로 제공하기에 이를 사용하기로 하였다.
물론, 다른 무료 서버들도 많이 있다. 선택은 사용자가 적절히!

[Public MQTT Brokers]
https://mntolia.com/10-free-public-private-mqtt-brokers-for-testing-prototyping/



테스트 서버의 접속 url은 http://test.mosquitto.org/ 이다.

접속 port에 따라서 서비스 형태가 약간 다르다.
  • 1883 : MQTT, unencrypted
  • 8883 : MQTT, encrypted
  • 8884 : MQTT, encrypted, client certificate required
  • 8080 : MQTT over WebSockets, unencrypted
  • 8081 : MQTT over WebSockets, encrypted


IoT의 소형장치들은 대부분 보안에 취약하다. 이는 미래에 큰 화두가 될 것이다.
나는 테스트를 위한 (보안이 필요 없는) 정보를 주고받는 정도이므로 1883 포트를 사용한다.

무료가 항상 그렇듯 본 서비스도 donation을 받는다. 한달에 약 $70가 운용비용이라고 하는데, 설마 이정도도 ECLIPSE 재단에서 지불을 못할까?

테스트 해보니 속도도 빠르고 별 문제가 없어서, 앞으로는 본 서비스를 활용할 계획이다.