Project Logs

Collapse

• Let's dance

  Stefan • 12/24/2020 at 10:25 • 0 comments

  Well actually not very sophisticated, but still a bit autonomous. Until now, the 4WD robot platform was actually more of a remote controlled car, as the speed always had to be controlled manually. Now with the adapted motor control a line follower is a matter of 2-3 lines of code, because all sensors are already on board.

  As you can see on the OSC layout I changed the approach of the control a bit. No longer left and right motor, but speed and direction. This is much easier for the autonomous control.

• Manage the robot speed

  Stefan • 12/20/2020 at 20:56 • 0 comments

  I was not active in this project for a while, first because it was actually made for the Hack a day prize 2017 and I had not won anything ( -> therefore no more log's) and second because I had problems with the speed:

  Actually it's nice if a robot can go fast. But for most tasks and especially for programming new it needs low speeds. Exactly that went very badly. With a lot of finesse, it was possible to adjust the controller so that it just barely started, but once the initial friction was overcome, it quickly built up speed. In addition, the initial friction is very dependent on the ground and thus cannot be fixed with absolute.

  I tried different P and PID controllers. The encoder with the magnets and the Hall elements has quite large tolerances around 20%and vary around 5% with speed.

  Since these are inherent variations in the system, they can be reduced to less than 10% using a correlation function, but then the tolerances of the 3D printed mechanics become noticeable and cannot be further eliminated:

  These large variations, combined with the few pulses (only one pulse every 28mm of travel), mean that in practice no useful results can be achieved with a controller. Thus I lost interest in the 4WD robot platform.

  In the Corona time one has (unfortunately) again much more time. In the process, I came across an optical AI sensor and thought that this would be the optimal platform for the sensor, so I tried again - and succeeded.

  The ESP-IDF offers MCPWM for the motor control. For the use also with the Arduino IDE there are quite a few examples. Mostly implemented with Joao Lopes ESP32MotorControl library, which I also use. Exactly with this, however, slow driving for robots is prevented. Basically the motor control works with a PWM signal. I.e. at slow speeds one pole of the motor is set to HIGH for a short time and then taken back to LOW, while the other pole is always at LOW. At higher speeds, the duration of the HIGH signal is simply extended accordingly. This creates a freewheel while both poles are at LOW and the robot becomes much too fast. Correct would be to brake the momentum of the motor during the inactive. This is achieved with most H-bridges by setting both poles to HIGH. I changed the ESP32MotorControl library accordingly and can now control the speed from very, very slow to full speed very accurately.

• First experiences and next steps

  Stefan • 07/02/2017 at 19:28 • 0 comments

  In general the robot platform works quite well. But as it’s a work under progress there are still some improvement potentials resp. things to solve:

  GPIO 38 does nothing

  As the AD2 of the ESP32 doesn’t work when the WiFi is switched on all GIOP’s made available for extensions by the AUX connector were chosen from AD1. The GPIO 38 can be used for input only according the manual. In my case this input does nothing at all (I read that someone has the same problem so I assume it’s not a wiring error). However I linked now that position of the connector with the reset input. This allows peripherals to pull the reset which is helpful for development.

  Battery status

  With LiPo’s the charging state should be always kept in mind. The robot platform doesn’t report this state due to a lack of free analog inputs. If required it can be easily managed by the AUX connector from the periphery. Just connect a 10k resistor between Ubatt and GPIO33 as a 2,2k resistor from GPIO33 to ground. The voltage can then easily reported via OSC to the remote control (If you suse the same remote control as described earlier)

  Speed

  The robot is pretty fast. For example an application in which the bottom proximity sensors should prevent the robot falling down a stair will not work at full speed due the braking distance the robot requires (About 5cm at full speed – even with slow decay as described in the last log). Of course allows the H-Bridge to control the speed of the motors but they lose also torque at low speed. In order to avoid this either a software PID is realized. This is still work of progress but should be good possible to realize as the timing reported from the hall elements is very stable (30ms –200ms).

  An alternative promises esp-idf (the ESP32) with the lately mcpwc command. As this is unfortunately not yet documented for the Arduino IDE it remains work under progress for me as well at the moment.

• Low level DC motor driver

  Stefan • 06/18/2017 at 19:17 • 1 comment

  The motors are driven by a DRV8833 dual H-bridge circuit. The principle of such a control is pretty simple, the H – bridge hold one terminal of the motor to ground while the other is set to Vdrive. For the reverse direction it’s just the other way round.

  The bridge is controlled by two inputs for both side of the bridge and if they haven’t the same state the motor turns in one or the other direction. You’ll find a very detailed explanation about here: http://www.modularcircuits.com/blog/articles/h-bridge-secrets/h-bridges-the-basics/.

  To control the speed of the motor a PWM signal is applied to one input while the other input is hold to LOW. A PWM signal is what is generated with the Arduino when the analogWrite() procedure is used. In the current stage the Arduino IDE for the ESP32 can’t do such a analogWrite() procedure not yet exactly, a espressif call is required therefore – this is why the drive on github is still in development state, but it has been promised that even a much more accurate driver function will come. – For an analog output the ESP32 would have even to DAC for a real analog value but they can’t be used with the H-bridges.

  Theoretical it would be also possible to keep one input of the bridge on a HIGH state instead of a LOW state while applying a PWM signal on the other input. This would change the turn direction and changing the control from fast to slow instead from slow to fast but would work as well. In the same way? Not in the same way exactly as the datasheet of Ti shows:

  The table shows that in this case “slow decay” instead of “fast decay” will be applied. The difference between those two modes is that the terminals of the motor are either shortened or open while the not powered phase of the PWM cycle.

  This means with “Fast decay” the robot is just free rolling while there isn’t power on the motor while it does kind of break speed depended in the “Slow decay” mode. This has no impact on the top speed only the movement should be more accurate and the way to stop should be shorter. The last should be of relevance for this robot platform. This as the max speed is that high that it needs to be reduced pretty much when realizing a line follower. The “Slow decay” mode should help to increase its reactivity for such an application.

• Smartphone remote controller

  Stefan • 06/16/2017 at 19:35 • 0 comments

  The sense of a WiFi/BLE enabled platform is the capability to control it remotely via WiFi or BLE. A smartphone is capable of both but by far not that easy to program as an ESP32 with the Arduino IDE. For all which are not capable of doing this the OSC protocol offers a very simple way to turn the smartphone into a bidirectional WiFI remote controller.

  There is e.g. the TouchOSC app which can be loaded on the smartphone (not for free), an OSC library for the Arduino and a free editor for TouchOSC which allows building layouts on the computer and afterwards uploading it to the smartphone. With a remote control interface on the smartphone easily can be realized which works in both directions. To describe this in detail makes not too much sense as there are some tutorials for this on the web e.g. this one https://trippylighting.com/teensy-arduino-ect/touchosc-and-arduino-oscuino/

• Putting all thogether

  Stefan • 06/15/2017 at 18:52 • 0 comments

  When the controller and the housing are assembled the wheels can be placed. Therefore the gears with 8 teeth (6 pcs.) and 12 teeth (2 pcs.) need to get equipped with a brass axle. A 3mm brass rod can be used for this and will stick well in to the gears. The axle length for the 12 teeth and 2 of the 8 teeth gears is about 10mm while other 4 axles (were the wheels are placed) needs to be about 18mm in length. As mentioned the dimensions allows just pressing them into the gears and wheels without any further fixations. But as it’s possible to press them under an angle into the wheels a simple gauge should be used.

  Then the ball bearings can be pressed into the housing which sticks pretty tide without any further fixation as well. But they needs to be placed with the gears and axes in place! This is important as the fishbone structure holds the gears in place. On the other hand this prevents to place one gear after the other once the bearings are in place.

  Then connectors for the front proxy and the bottom proxies (female pin headers with epoxy putty) need to be connected to the ESP32 board. As they needs be feed through the housing respective screws are underneath it requires some longer wires for the capability to move them. This excess wires are winded up on top of the ESP32 board when finally assembled (feed them under the AUX connector). The platform is designed to incorporate an APDS 9930 I2C sensor as front proxy.

  The controller can be placed with 4 screws into the housing (not to forget to connect the connector for the LiPo in the correct polarity!). As there is only a little space I dragged the heads of the M3 x 8 down to 4.5mm. But those screws shouldn’t tighten too much as the gears get friction otherwise.

  On the back end a buzzer can be placed.

  
  

  Finally the top is screwed on.

  
  

• The gear

  Stefan • 06/14/2017 at 20:21 • 0 comments

  The robot platform has wheels with 3cm diameter and a gear with a 3:1 relation. This allows quite a high speed, offers still enough power to drive the robot and the ESP32 allows programming the drive to move also with low speed. Gears with a particular no. of teeth and with a certain diameter are difficult to get. Because of this they are all printed for this robot platform. With a hobby printer gears with an M=1 down to M=0.7 can be printed in the highest resolution usually. Therefore all gears are based on M=1 and as the motors have a gear with M=0.7 they stick directly to the shaft of the motor. In order to avoid any asymmetry the gears needs to be printed with a raft. But even with this I can attach the main gear only from one side to the M=0.7 shaft of the motor.

  This robot uses ball bearings for each axle. Simple brass shafts could do probably the same but didn’t work in my first trials well enough so I changed to the ball bearings. I the first trials I had also standard shaped cogwheels. But as such a setup needs to have a fixation in the bearings I changed to herringbone gears. They fix each other in the longitudinal direction which use less space and reduces the friction.

  It is very helpful for a robot to have encoders in order to determine how much turns the wheel did. This is often done with optical sensors but require also pretty much space. In order to avoid this magnetic sensor, a hall element is used for this robot. Most hall elements are like switch, on when they are in a strong enough magnet field, off when there is no field (or a field with the wrong polarity). A basic setup works when a wheel hosts a magnet and turns in front of a hall element. In the case of this robot only the big wheel attached to the motor allows to build such an arrangement. But due the transition this wheel also turns slowest. Therefore an as much as possible magnet needs to be placed into the wheel to get a good resolution. The printed wheels have a diameter of 3cm and the motor turns once for three turns of them. Having only one magnet leads to one impulse per 28.27cm distance the robot makes - which isn’t that exiting. So I did trials with cylindrical magnets with 1, 2 and 3mm in diameter. With the 3mm magnets a maximum of 6 magnets is possible while more than 12 magnets could be placed with the 1mm diameter magnets. But I made the experience that the 1mm magnets are to weak to grant a reliable impulse, even when 2 or 3 were placed in the same hole (“in series”). So I used finally the 2mm magnets and was able to place 10 magnets per wheel (a higher number of magnets prevent the hall element to detect each of them).

  Even those magnets are really tiny, they easily can be fixed in the wheel. The holes are slight faceted are a little bit smaller than the magnets. Simply place them on a pre-magnetized screw drive an press them gently into the foreseen hole. To pre-magnetize the screw driver helps to place them with the same polarity into the wheel (keep in mind: the hall element is polarity sensitive).

• The housing

  Stefan • 06/13/2017 at 20:46 • 0 comments

  To assemble the housing is pretty simple except the wiring is a bit demanding. The shell hosts 4 CNY-70 IR proximity sensors, for a line follower or to detect the table edge and 2 LED’s as head light. Those electrical elements need to be connected with 3 connectors. One each for the front and rear proxy’s (both connected to the bottom proxy connector – see wiring diagram) and one for the LED’s. In order to keep the connectors as small as possible they can be made of pin head

  ers and epoxy putty as described earlier while a connector for the LED’s can be placed on the side. All resistors as per the wiring diagram needs to be placed direct on top of the sensors and LEDs. Especially the resistors on top of the CNY-70 needs to be kept as short as possible as they will touch otherwise the screws which holds to top cover. For the connection between the sensors and the connectors very thin wires should be used (e.g. Polyurethane enameled copper wire 0.2 mm) and then carefully be glued to the wall. They should run parallel and not cross each other as there is no space left else.

  In total 12 M3 nuts needs to be placed in the housing. They are for holding the front and back sensor (or beeper), the controller block and the top cover. All those nuts should stick by them self in the plastic. The nuts for the front and back sensor should be mounted with care as the bottom wall is very thin.

  
  

• Controller

  Stefan • 06/12/2017 at 18:30 • 0 comments

  Well, an absolute newbie in soldering might have a hard time with building this robot. For the power wires some AWG 26 can be used while all other connections should be done with a thinner wire as for example 0.2mm polyurethane enameled copper wire.

  The controller holder 3D print sits on the LiPo and is made to hold all electrical modules as shown on the pictures. There are different breakout modules for the various electronic elements available. The picture shows the particular models the 3D is designed to. With these picture it should be easy to find an appropriate in the various internet shops. ESP32 Thing is the ESP32 development board from Sparkfun and had the best dimension (at that time).

  In order to ensure the capability to disassemble the robots some connectors are used. Most of the usual connectors are to big in size for this compact robot. Instead this connections can be made with pin headers. The LiPo connector has a pin header isolated with heat shrink tubes.

  But as this consumes to much space for the other connectors their isolation can be done with epoxy putty. By the way, the LiPo connector here is made with 3 pins – Ground on both outer pins – in order to avoid a wrong polarity.

  The wires from the DC-DC converter, the LiPo and motor driver can be routed between the motors to the back. As it’s nessecary to flip up the ESP32 board for accesing the screws, all wires needs to be feed under the AUX connector from the back side to the controller board.

  The connectors for the front side proxy (I2C) and the connector for the bottom proxies needs to be movable while screwing the controller module into the robot. Therefore the wires need to be made long enough. When assembled the excess wires can be winded up and be placed on top of the ESP32 board.

View all 9 project logs