ExplorerBot is a robot that can explore flat environments and produce a 2D map of them.
- 2 x Arduino Uno
- 2 x RF24Lo1 radio module
- 2 x Parallax continuous rotation servo
- Adafruit BNO055 sensor board
- Turnigy 1.25 Ah 3S LiPo Battery
- Turnigy 40V SBEC
- 2 x HC-SR04 Ultrasonic distance sensor
- Jumper wires
The ultrasonic distance sensors will allow the robot to see the environment and map it. The adafruit sensor board will allow the robot to keep track of its orientation. In combination with the distance sensing, it should be able to keep track of its relative position with only a small amount of compound error. The continuous servos will drive the robot. The PWM signal sent to them controls both speed and rotation direction. The main logic of the robot will actually be handled by the laptop, so it will need a wireless link to send and receive data so the robot will be equipped with a radio module. My laptop can’t interface directly with the other radio module, so a second arduino will act as a relay, sending the data to the laptop via serial over USB. The robot is powered by a LiPo battery. Since the battery puts out 11.1V nominal, it’ll need to be regulated to 5V and 3.3V for the components. The Turnigy SBEC will handle the 5V regulation. From there the arduino will produce the 3.3V for the radio module. The arduino could do all the power regulation for the robot, but it isn’t capable of much current. The dedicated switching power supply can handle 5A, so there should be no problem there. The battery is capable of about 40A at 11.1V, so it has loads of headroom. These components are far from ideal for this project. I chose them because I already had them and am familiar with them.
I measured up all the components with my digital calipers and placed them in a virtual environment for 3D modelling. I used Blender for all the modelling because it’s the only software I have for it and because I am very familiar with it. I modelled the body parts of the robot around the virtual components so I knew they would fit. I then exported them from Blender, and opened them in Cura, the software I use for 3D printing. Cura slices up the model and produces G-code for the printer. The G-code is a long list of instructions that the printer follows to print the part. I then powered up the printer, got it up to temperature (205°C) and printed the parts for the robot. The main body piece had to be printed separately as it was too big to fit on the print bed with everything else.
I had initially designed a roller caster that would balance the robot, keeping it level. I didn’t notice that Cura had not sliced the thinner sections that held the balls. instead it cut the print short. This appeared to be because the walls were to thin. I redesigned, opting for simpler posts with rounded ends. These printed without a problem and ended up working very well.
I then assembled the robot. Everything fit well, except half of the screws for the servos. I found that 2 screws in each were enough to secure them anyway, so this didn’t cause an issue. I then wired everything up. I spliced some wires together for the power delivery as there weren’t enough connectors on the arduino itself. I knew I would have to do this, but also knew it wouldn’t be a problem doing so. I then wired up the relay arduino to its radio module.
With the hardware completed I moved onto the software. I decided to do all of my data transfer in ASCII so I could read it all for debugging. It also made handling when a transmission starts and stops a lot easier. The relay code is relatively simple. Just listen to both interfaces. When you start receiving on one, read it into memory, then write it to the other interface.
The code for the robot’s arduino is more complex. On top of being able to receive and interpret instructions, I wanted the robot to be able to do repetitive tasks with just a single instruction, rather than the laptop sending out loads of simple instructions, so I wrote functions for setting bearing and sweeping for distance information. I also wrote simpler functions that the more complex functions would use. These functions could also be called directly if the laptop program needed a specific bit of data. I also did some component calibration and baked it into the robot code. This helps the robot do exactly what it intends to, and help it see exactly what it should.
The laptop code will be in the next part of the project.