• Perseverance pays off

    Ulrich • 03/17/2018 at 09:20 • 0 comments

    This is very slow going: Every single feature is a problem and needs to be solved with a great effort.
    However there is progress. :-)

    In the last three weeks:

    • I changed the board (3 times). This time with self-made boards (in a maker space). The current version uses a smaller ESP32 board which is moved away from the camera. And there is no ground plane anymore.
    • Changed the motors back to smaller ones but this time with encoders.
    • Changed the wheels (and chassis) to a slimmer one. The tires I use are spare portafilter parts - and the rims printed to fit them.
    • Motor control with the help of the encoder input is now done with a PID controller.

    Overcome problems:

    • How do interrupts work with the ESP32? Fairly ok (simple examples work). But take care of the connectivity: Changes in the connection quality ie of fly wires generate lots of interrupts. Also take care on accessing the counter variable. Using them directly for "Serial.print" shows lots of garbage and/or crashes.
    • How do encoders work: ie what number of ticks per revolution? Mine do not seem to conform to the "spec". Consider the motor reduction correctly.
    • PID: Understand, reverse engineer and fix the pid library (https://github.com/br3ttb/Arduino-PID-Library/) to make it fit for use with motor control. E.g. with the current version errors do not dissipate when the motor is stopped thus pid output is continually != 0 but the motor does not turn (too weak for small values) and it should be stopped anyway.

    Open problems:

    • The camera problem seems to be much improved with the distance between it and the ESP32: Much less dropped packets. But the general WiFi reception seems to be even worse than before: 3 meters open line seems to be the maximum for the current design.
    • The current PID control cannot correct small errors. Thus a "straight ahead" has still a small drift to the right now.
    • Even with the encoders the motor control is still difficult: PWM values do not correspond linearly to speed with these motors. And there is a large gap at the low values where the motor simply does not turn.
    • The tires are insufficient: much too sleek. Combined with the motor weakness they often spin freely. A simple rug is testing this to the limits. And small obstacles cannot be be surpassed.

    Next stop: Try stepper motors.

    Problem: Normally these are big or very big and most require much more current power.

  • More of a move

    Ulrich • 02/27/2018 at 09:09 • 0 comments

    What I did and improved in the last two weeks:

    • Designed, ordered and used a professionally printed board
    • Changed the motors for bigger ones (a bit more slowly rotating)
    • Thus changed the prototype chassis to a much wider one - it is now too wide for practical use I think
    • Debugged and (partly) found an odd Wifi transmission problem: The camera interferes severly with Wifi transfer
    • Written an Android app for image display and remote control

    Now there are some problems still or newly open:

    • The camera interference is not solved (https://github.com/ArduCAM/Arduino/issues/301) - I improved the situation a bit by using an aluminum shield between camera and ESP32
    • The motors are very different (left and right) and generally without any control over them (-> encoder) the movement cannot be sufficiently controlled
    • Delay from the camera capture (200ms at least) and the poor Wifi transmission make a very sluggish image transfer and thus the control once the vehicle is out of sight is nearly impossible

    But still: Something moves remote controlled!

  • Moving prototype

    Ulrich • 02/10/2018 at 09:23 • 0 comments

    A replacement esp32 board arrived and the car now actually does something (desired).

    I now have:

    • Image display and rough control: a webserver serves the current image in a stream and another server (different) port reacts on control requests - currently only bursts of forward, reverse, left and right.
    • Motor control (PWM) with soft start and stop
    • All of which with a pre-emptive multi-tasking so that image transfer does not block everything else

    Next steps: Android app for finer control and home-made PCB (properly designed).

    Note the color tinge from the ir-sensitive camera - lens without ir filter.

  • Fried prototype

    Ulrich • 02/04/2018 at 11:36 • 0 comments

    There it is a very first, fully integrated prototype.
    It has camera access, image wifi provider, motor driving and power supply from a single, small li-ion cell - stepped up for the motor driver.

    However I couldn't really get the motors to work on this particular board. Something with PWM not working and/or having noise during boot.
    And in the end I managed to fry the Esp32 (nodeMCU). It now gets very hot very fast when plugged in.

    Looking at the wiring I get the distinct feeling that this needs a professionally printed board.
    However before designing and ordering that I'd like to test this in order to pick the correct pins to wire for example...

    The short wire roughly in the middle actually did short with the pin below.

  • Very first prototype (thing) for images

    Ulrich • 01/26/2018 at 15:45 • 0 comments

    After ditching the attempts on bluetooth and 3 hours of soldering and sawing I got a very first prototype that shows off image transfer (WiFi now) and tests lighting and overall performance. It incorporates a revolutionary wooden mediator board that enables connection to a swan neck. ;-)

    So I can very proudly present the very dirty (of course) view at the space behind my washing machine.

    After pushing that one back in its corner (below the kitchen work surface) I wanted to check if I bent any of the tubes. Now I can.


  • Some steps back and some forward

    Ulrich • 01/26/2018 at 15:42 • 0 comments

    > I know now this device is "classic bluetooth" but I hoped / guessed that modern bluetooth implementations would also support that...

    Alas the ESP32 BLE library does not do that. And also a quick low level test didn't work.

    > The problem(s) I have now for several hours though: How can I guarantee that data transfer is finished before closing the request?

    It turns out that it was not the reply but the handling of the request that prompted Firefox to always show "connection broken": One needs to actually read the request to satisfy Firefox.

    With that in mind serving a captured image works ok. With an HTTP-Refresh it even updates continually.

  • Camera image in the debug view

    Ulrich • 01/21/2018 at 16:23 • 0 comments

    I tried and researched my bluetooth problems for a few hours more: The HZ-RM1 will not be found by ESP32 (BLE library).

    I know now this device is "classic bluetooth" but I hoped / guessed that modern bluetooth implementations would also support that...

    I had however some success with the camera:

    I ordered an ArduCam (2MP model) and got that connected to the ESP32. I tried for some time to use the hardware spi (HSPI) but then the ESP does not boot anymore if the MISO pin is connected to the cam. It works however with the VSPI pins.

    I patched together some example code from the examples of ArduCAM and the ArduCAM ESP32 code (old one) and some wifi and webserver examples.

    With this the camera is accessible and can capture and provide an image. I serve that with a simple webserver on my local wifi for any request.

    The problem(s) I have now for several hours though: How can I guarantee that data transfer is finished before closing the request?

    The most I can achieve at the moment - with some luck - is that the browser gets and shows the complete image in the network monitoring view. The browser page itself *always* shows a "connection broken" though.

  • First real no connection to bluetooth

    Ulrich • 01/20/2018 at 10:22 • 0 comments

    I ordered and received an ESP32 now for my bluetooth experiments.

    I want it to connect to my HID device (a Hizek HZ-RM1). A sort of handheld joystick which would be ideal as a remote control.


    Alas after 5 hours: no show.

    I used/tried the "BLE_scan" example of the ESP32 integration in Arduino IDE. This seems to work (upload and output) but it only finds zero to one devices (maybe from neighbors) but not the ones I am testing with.

    My smartphone on the other hand has no problems finding and connecting them...

  • Lost vehicle

    Ulrich • 01/13/2018 at 09:19 • 0 comments

    I found a small snag with my plan:

    > I want to explore the raised floor in our office and search for mice.

    What if the device breaks down or gets stuck while doing it? It would be unreachable for any conventional means.

    And I can imagine quite a lot of reasons for it getting stuck. Especially during the beta test runs...

    So it either must have really good (intelligent, self-driving) recovery features or at least a small leash to tow it back.

    On the bright side: Others faced this problem too: I.e. Mars and asteroid exploration devices.

  • Powering bluetooth module

    Ulrich • 01/13/2018 at 09:08 • 0 comments

    > The JY-MCU should show up for other bluetooth devices (ie for my computer). However it took 30 minutes until it did that.

    The reason might be that the 3.3V from the esp8266 with which I powered the JY-MCU is not enough to power it properly. Directly with the battery (3.9V) it works better.