Wow! More than a year has passed since the last post on the topic of Robotics for Kids. Then again, year 2020 was a “special” year with lots of good things happening for me on a professional (and personal) plan, but also “some” bad things happening that affected the entire world. No excuses!
In this second article in the series, I further challenge my older daughter by programming a line follower.
Disclaimer: this has nothing to do with the topic at hand. I like the products from DFRobot, but I also happen to have an opinion, so let’s clear few things right away, shall we DFRobot?
- For a company self-promoting as “a world-leading robotics and open source hardware provider“, a company which inevitably benefited from open source and open hardware, you need to give back to the community! Why am I saying this? Well, for one – your definition of open seems selective. When I wanted to dig deeper into the Maqueen chassis, I couldn’t find any schematic and it seems there were other of your customers who wanted the same – and each time they were redirected to the product’s wiki page.
- On the topic of wiki pages – some of them feel incomplete – it seems you choose what you want to publish, rather than what the user wants and/or expects from an open educational platform built on top of a another one. At the time of this writing, I checked practically all of your products wikis, and the only products where you actually publish the schematics – are those (e.g.) simple interface adapters.
- The wiki you seem to be pointing out for all those requesting and expecting more on the product they have purchased (i.e. the Maqueen robot chassis) and also the one I hyperlinked in my previous post – no longer exist or it’s plain empty!?
- Your affiliation or rather dependence on open source is evident, yet the links to your SW’s and SW libraries’ source code for your products are not that evident (if at all!?) in the products wikis. Instead, I have to use web searches and hope I get a hit! What’s up with that!?
- Much like another customer, I posed the same question of where may I obtain the Maqueen’s circuit diagram – almost 2 months ago and still waiting! I even pointed out it’s not super complicated and that someone with descent skills and a multi-meter could probably reverse engineer the hardware and the circuit diagram – which btw, is what I did – at least the part I was interested in i.e. the control of the 2 motors.
I could probably point out a couple of other things, but I will stop as I am getting further apart from my intended topic.
So… What is a line follower? A line follower robot is typically a robot who’s sole purpose is to efficiently and effectively navigate around a closed path (sometimes also in the shortest time possible!) consisting of straights, corners, ups and/or downs. Typically, the path could be made up of a visible black stripe on a white surface, but it could also be made of a magnetic one.
If we restrict ourselves to a circuit path made up of a black stripe on a white surface, the “sensor” could be made up of just two IR sensors (L-left and R-right) or an entire array of IR sensors.
Let’s imagine we have only two such IR sensors i.e. IR_L and IR_R (consequently, this is what the Maqueen is equipped with), then the algorithm for navigating around a path could not be simpler:
- If both sensors are positioned over the black stripe, the robot moves forward
- If (only) the IR_L sensor is positioned over the black stripe, the robot moves in the opposite direction i.e. right
- If (only) the IR_R sensor is positioned over the black stripe, the robot moves in the opposite direction i.e. left
- If neither of the sensors are over the black stripe, the robot moves backwards
The backwards movement is not really efficient (especially when one of the requirements is the shortest lap time) but serves it’s purpose when we are dealing with only 2 IR sensors and a simple algorithm to keep the bot on the line as much as possible.
Having defined our simple algorithm and explained the whats and the whys, I gave the “controls” back to my first officer (my daughter) to transfer it in a Scratch-like programming environment called Mind+.
After some tweaks here and there (mainly around the movement speed of the bot) and some debugging, her Scratch classes proved useful and this was the result:
There are four variables set for the speed or velocity, when in essence, we could perfectly go with just three (if not even two?): forwardsVelocity (or ForwardsV), backwardsVelocity (or BackwardsV) and just turnVelocity (or TurnV) – instead of LeftV and RightV.
The last point out of the ordinary – is the delay of 0.1 seconds and the complete stop of the motors. This may not be needed at all, but we found it helps the bot cope with sudden changes.
Then there’s the value of the bot’s movement speeds – they are very low! The forwards speed is for example 1/5th of the maximum. But what we noticed is – if anything above that, the bot doesn’t follow the algorithm correctly!?
I personally suspect it’s the Mind+ environment and the abstraction behind it! But first of all: why? Second of all: can I prove it? … and that’s where ‘kids’ in ‘robotics for kids’ ends.
First the why? Most likely because of the micro:bit runtime:
Next, can I prove it? Well, I could try.
First, I needed to understand the hardware for which no schematic is offered. So I took a couple of pictures and started looking for the components datasheets:
That 75V18 seems is a typical motor driver IC found in Chinese toys and the schematic diagram suggested in the datasheet, copied fully into the robot chassis to the last capacitor value. Checked and confirmed.
PC6, PC5, PD2 and PC7 are all ports on the chassis’ microcontroller, which was difficult to get the component designator from, but after a while I managed to read this out: S033 PHVG 821Y, which most likely is a ST copy – an 8 bit STM8S003F3 copy of to be exact.
Okay, so the STM8S003F3 micro is (I suppose) the I2C slave and BBC micro:bit is the I2C master. The values of 0-255 (for the speed of the bot) sent to the STM8 over I2C, I suppose generate a PWM signal on the identified pins of the STM8, which in turn, vary the output voltage on the two 75V18. This is as far as I could go with only a multimeter.
After some poking around, I found this GitHub repo on the Maqueen chassis. In it, there’s a file called maqueen.ts, and it’s contents pretty much explains the message that is sent to the STM8 from the BBC micro:bit that controls the speed and direction of the two motors. To confirm it, I set my Arduino UNO as a slave device – giving it the same I2C slave address as the suggested one for the chassis in the maqueen.ts file, and ran a loop changing the speed and direction with known values – using the Mind+ environment – and everything received on the I2C bus, I just forwarded it to the UART of the UNO.
This basically confirmed the maqueen.ts file:
- The 1st byte is the motor ID (0x00 – M1 or left motor, 0x02 – M2 or right motor)
- The 2nd byte is the motor direction (0x00 – forward and 0x01 – backwards)
- The next 1-3 bytes are the speed or velocity of the motors (e.g. 0x00 – zero speed, 0x31 0x32 0x37 – speed at 50% and 0x32 0x35 0x35 – speed at 100%)
The next step was to figure out how to use the online mbed IDE and write the code to control the BBC micro:bit – as close as possible to bare metal (well, kinda bare metal) – using as little helper libraries as possible.
As always, the source code is available in my Bitbucket repo. The code is not complicated at all – just a bunch of functions, wrapping around the info I got thus far and performing the necessary bot movements.
The improvements were visible! The bot could handle the simple line following algorithm much smoother and and at higher speeds. YouTube videos coming soon!
And this wraps it up for this post – even if I went further than the intended robotics for kids.