We’ve got our electronics ready for our robot, Mr. Bit. Firstly, as it’s “Pi”Wars then a Raspberry Pi must be at the core of the robot and be the master controller to the rest of the electronics. We will need motors so he can move around and motor drivers to power them. There are two batteries, the first is a 5v power bank (phone charger) that will plug directly into the Pi, the second is a higher voltage battery pack (6v or more) that will be used to power the motors.
The challenges in PiWars are either “remote controlled” or “autonomous”. We will use the onboard bluetooth of the RPi3 and connect this to either a PS3 controller or to a phone (we have to investigate this). The Pi will receive instruction from the controller then send the relevant instruction to the motor driver to drive the motors.
We have chosen a SparkFun Monster Moto driver as it’s similar to the ones we read about the efficiency, control and tolerance of the VNH2SP30 driver chips it uses – there are some Polou drivers similar and these were our number one choice but we were able to find these Monster Motos much cheaper.
The motor driver not only takes in power from an external source and distributes it to the motors it also accepts a PWM input to alter the speed of the motors. The Pi only has a single hardware enabled PWM GPIO pin (pin 18) so would have to try to replicate PWM from software – also though the max voltage by the driver chips is 5v and the Pi GPIO pins have a max output of only 3.3v which may result in poor performance of the driver chips and motors and ultimately reduce our speed in the competition.
The Monster Moto is actually designed to be an arduino shield though it doesn’t have to be used in this way. The Arduino uno (we’re using a seeeduino) has 6 hardware enabled PWM pins with max voltage of 5v, so we can drive 2 motors at max power. The motor driver also has 2 output pins for “current sensing” – one for each motor. The voltage from these pins can be read and the current of the respective motor known. If the current is getting too high for too long for example then there is risk to both the motors and the board – detecting this could form a part of a protection algorithm. The current is variable and so the an analog to digital converter is needed (ADC) – the Pi doesn’t have ADC but the Arduino does, another reason why it’s better suited to the job of controlling motors.
The Pi will send the commands to the Arduino which will in turn control the motors as well as feedback information to the pi about how the motors are coping. I’m not yet sure how the Pi will talk to the Arduino, it could be USB or I2C or something… The following is a block diagram of how Mr. Bit’s components interface with each other.
There are three challenges that require the sensors attached to the Seeeduino in the diagram above. These are the autonomous challenges:
- Minimal Maze – Mr. Bit will need to know where walls are and so needs a distance sensor
- Line Following – where a line needs to be tracked, this requires an IR array
- Straight Line Speed Test – where the robot can’t hit the walls of a channel that is raced down. This again needs distance sensors but also, as the floor of the channel is red and black, the IR sensor array may be able to detect when the channel ends too.
We have chosen Sharp IR distance sensors and Pololu IR sensor arrays. The IR sensors are analog sensors so, again, they require an ADC. The Arduino has the ADC so it makes sense for them to be interfaced into the Arduino here. I’m not sure at the moment if the Arduino should send the readings back to the pi and then for the Pi to decide what it wants to do and send the decision back – or if the Pi puts the arduino into a sort of auto pilot mode for these challenges – I’ll have to look at the pros and cons for each.
Now though I want to test the motor driver out, get the pi talking to the arduino and maybe send a command from a PS3 to the Pi – so the sensors can go in the drawer for a while as we get the very basics sorted out first.