My Robot is controlled by the ArduinoMEGA2560.
Quite all the features of the MEGA2560 are used: 3 Serial interfaces, I2C, SPI, PWM, ADC and 2 interrupts. This is whyI have chosen the MEGA2560 which offers such large number of interfaces. But note that MEGA2560 is a little bit limited regarding the interrupts because 4 of the 6 interrupts are not available if I2C and Serial2 are used.
The only features missing in the MEGA2560 are Bluetooth and WIFI connections. For this purpose I have added one nRF52832to handle Bluetooth and one ESP8266 for WIFI processing. The first one managest he commands received from the user interface running on Android, the second one send data and pictures to a Raspberry PI.
Initially I have used also an ESP8266to manage command received from a my PC on Windows but the WIFI was too much power consuming so I have migrated this part to Android and BLE Bluetooth, so now the commands are sent from my mobile.
DevicesNow let’s discuss more in detail about the devices implemented. Below the list of devices.
nRF52832
ESP8266
4 motors
2 H-bridges
2 Contact sensors
Sharp IR
Servo for IR
3 ToF
Compass
LCD
RGB led
Buzzer
Camera
Tilt&Pan servos for Camera
SD Card
RTC
Brightness sensor
Temperature & Humidity sensor
Motion sensor
Sound sensor
First of all, there are 4 motors controlled by 2 H-bridges managed using PWM and digital pins. They have a dedicated alimentation Li Ion in order to not disturb the MEGA2560 but don’t orget to connect the ground otherwise PWM will not work.
In order to allow the robot to run independently, the following devices are implemented:
- 3 Time Of Flight TOF connected to I2C indicates with a good precision the distance (max 1, 20 m) between the robot and a potential obstacle. One TOF is set on the front of the robot, the 2 others are set on the left and right sides with an angle of 45° from the front. Their pin Shutdown is managed in order to set different I2C address for each device. Theyare configured to allow measure every 33ms if required. Only the median from a sample of measures is taken in account in order to avoid erratic measures.
- One IR Sharp connected to ADC and mount on a servo checks the distance (max 0.80m) with an obstacle around the robot (left andright). Note that it is less precise than the TOF. The servo is controlled by PWM and allow to move the IR Sharp from -180° to + 180°, more than the TOF that are statics.
- 2 contact sensors are implemented on left andright side to detect hit, in case the robot didn’t detect the obstacle on time!
Each 165ms(33*5: nb sample measures), the Front TOF measure the distance between the robot and a potential obstacle.
If the distance is smaller than the Distance minimum, then, the robot turns 45° to the direction where this is no obstacle or it turns back if it detects obstacle on left and right sides. The IR Sharpis used to check obstacle around as it is mounted on a Tilt&Pan. A compassconnected to I2C provides the direction in order to control the turn. The robot follows also this procedure in case of hint detected by the contact sensors.
If the distance is between Distanceminimum and the Distance nominal, then the robot checks the distances measuredby the left and right TOF and push off to the best direction byaccelerate/decelerate the motor on a side.
If the distance is greater than theDistance nominal, then the robot continue to run straight forward.
The robot can also check the environmentand send alerts in case of abnormal changes. The parameters monitored are thefollowing:
· Motion is detected by a sensor that triggers aninterrupt on the MEGA2560. So this alert is in real-time.
· Temperature & Humidity connected to Digitalpin allows the detection of abnormal variation of temperature or humidity
· Brightness is also monitored by a sensorconnected to I2C
· I have tried several sound sensors buy none ofthem is adequate: they don’t detect whenI increase the volume of my speakers. Don’t hesitate to recommend one!
In case of alert, the robot takespictures using a camera mount on a tilt pan. So the camera can move from -180°to + 180° horizontally and vertically. The camera is connected to Serial3 and the2 servos of the Tilt pan are controlled by PWM.
The pictures are stored into jpegfiles on a SD Card connected with SPI. Then the MEGA2560 send them via Serial1 at38400 bauds to the ESP8266 Client and then to the Raspberry PI by WIFI with thedata captured by the robot
There are PHP programs on theRaspberry PI that stores in TXT files and in a MySQL database the datareceived. In case of alerts, the Raspberry PI sends email with these data andthe corresponding pictures attached.
In addition of all these devices, there are some other components to monitor the system: RGB led and buzzerconnected to digital pins, Real Time Clock RTC and LCD connected to I2C.
There are mainly used to understand inreal-time what is the doing the system as there is no more connection andlogging to the IDE standard Serial port when the robot runs. The log is writteninto a file on the SD-Card, with trace and RTC timestamps, so it can beanalyzed later.
CommandsThis robot can run independently buthe can also be managed by a User Interface UI running either on Android eitheron Windows.
On Windows, the UI is written in HTML/jQueryusing google widgets. As explained previously, the commands are sent via WIFI to a dedicated ESP8266 Server that interrupts the MEGA2650 prior to send it via Serial2 the command. So the MEGA2650 is not blocking to wait for a command, but he can manage it as soon as needed.
The responses are transmitted back to he ESP8266 and then to the UI. Note that the biggest inconvenient with ESP8266is the consumption, about 80mAh. So the LIPO 780mAh is empty after a couple of hours, so I need to switch off manually the ESP8266 Server as soon as I don’t need any more of the UI.
This is the reason why I have built another interface based on Android and Bluetooth.
This UI is written using MIT App Inventor that allows creating software applications for Android easily. The commands are sent via BLE Bluetooth usinga Serial service to the nRF52832 that interrupts the MEGA2650 prior to send it via Serial2 the command. So the MEGA2650 is not blocking to wait for a command, but he can manage it as soon as needed.
Note that the Bluetooth buffer is very small (20 bytes) compare to WIFI.
The commands are the following:
- Test IOT
- Check every n sec
- Stop
- Picture
- Move Tilt&Pan
- Check around
- Get data
- PI Communication mode
The ESP8266 Client is in charge sending Data and Picture to the Raspberry PI using WIFI.
In order to reduce consumption, it is always in deep sleep mode and it is wake up by a low pulse of 10ms to its pinDTR/RTS triggered by the Arduino prior sending any data or picture via the serial interface. Note that as the ESP boot procedure uses also Serial to log some information, the startup of the ESP was sometimes blocked to I swap the Serial pin of the ESP just after the start to avoid conflict with Arduino.
As soon as the data are sent, the Arduino send a sleep command the ESP to go back in deep sleep mode.
SoftwareIn term of software, I have written inC++ one lib per device and there is a main program Robot that handle the core processing of the MEGA2560 and thatcalls the functions in the libs.
At the end the program is quiet large, hopefully the MEGA 2560 has enough memory to run it, but for sure you can’t runit on Uno. Note that all the string for logging are stored in Flash memory to win space on data memory.
In addition there are 2 main programs for the ESP Server (Bluetooth or WIFI based) and the ESP Client.
There ara also some tools:
- Set the time of the RTC
- Store WIFI credentials in the flash memory ofthe ESP (so they are not displayed in Git!)
- Calibrate the Compass
Most of the code source has been found in the net (thanks to open source!) and then customized/improved. One key pointis that most of the time the sources found on the net don’t handle properly theerrors so I have completed this part, mainly on the I2C part.
Each device been tested alone with dedicated sketch before to be integrated to the core program. This is veryuseful to better understand the behavior and to know the limitation. For example, sometimes devices provide erratic measurements so it is more secure to get a sample of measures and compute the median.
The initialization part is also very critical and I have added for each device some tests cases during this phase in order to validate before starting that everything is ready. For example change the I2C address of the TOF in order to avoid bus conflicts.
I have also build a lib to define a protocol between nRF, ESP and Arduino to ensure a good quality of transmission on the Serial interface and to avoid deadlock. This is mandatory as the Serial interface is not secure, some bytes can be lost it the Serial buffer is full and the reader not ready.
Comments
Please log in or sign up to comment.