Raspberry Pi Line Following with QTR-8RC and WiringPi

Our Pololu QTR-8RC sensor has taken a lot of work to get consistent readings and line detection working from the Pi directly, we’ve persevered with it and IT WORKS! We’ve yet to find a good working example running directly from the Raspberry Pi so we hope this post will help others who are also trying to use the module. We now have consistent readings and calibration running directly off GPIO and Python. We have the code interfaced to our PID and motor control code and now Mr Bit is navigating our basic line track.

Firstly the mounting onto Mr Bit, we designed a basic bracket and printed it on our 3d printer, we have strengthened the bracket so it won’t shake with fluted joints and have created a slot on the arm of the bracket so we can fix it with 2 bolts – allowing for extension as we’d like to test with it extended at the front of Mr Bit.

screenshot of tinkercad

Drawing the bracket in Tinkercad

The wires fit through the bracket and under the pi, coming out at the side to plug into the GPIO. We learned how to crimp wires and insert into headers and pins over the past few weeks and we’ve wired 8 wires into a single block for all but the VCC which is positioned away from the rest of the GPIO pins we’re using.

close up of a group of wires inserted into raspberry pi

11 wires from the qtr-8rc plug directly into the GPIO (underneath the GrovePi+)

This single block is an achievement in itself for us and we’re glad to have discovered/learnt crimping – it means we can very easily plug and unplug the sensor (we’ve had to cut the plastic housing of the block to fit underneath the GrovePi which we’re using for our other sensors etc).

Full shot of Mr Bit and wires coming out of QTR-8RC sensor at front

We’ve tried to make the wiring as neat as possible, Mr Bit looking like a real robot!

The code we’ve written is python using wiringpi and we’ve (more-or-less) transposed the code from the Pololu QTR-8Rx CPP library – concentrating on the parts that are used specifically for the capacitor discharge version we have rather than the analog version. We previously posted about this in a basic form and now have calibration and read line functions working – there are a few tweaks as the time taken to run the python code on the Pi with all other system processes competing in the CPU means it’s not quite as responsive as a microcontroller.

The read line function gives us a value between 1000 and 6999 when on the line, a 0 or 7000 when off and having left from the left or right of the sensor respectively. Firstly we run a calibration by spinning Mr Bit over the line and then a prompt on screen asks if we’re happy with the calibration, we’ve added this as 9 out of 10 times we are but then there are some outlying situations where the calibration is skewed so we’d rather check than rely on it being good every time.

After calibration we’re set to go. We have a set-point for our pid which is 3500 (centre of the sensor), a very low base speed and very low constants – in fact at the moment we’re just adjusting the Kp (proportional) value, setting the Kd sets Mr Bit off in jittery convulsions. We’ve only done a few tests so far and looking forward to working more on it this evening. Here he is in action:

We don’t want to end up coming off the course like at the and of that clip!

One of the issues we have at the moment is the course we’ve made. We did make one out of paper but it got chewed up too quickly. Rebelle and I went to Hobbycraft on Sunday and saw some white A1 foam board on offer and got 4 sheets of it. The board itself is great to lay out and draw a line on with insulation tape, the glossy coating means we should be able to peel off the tape and create other configurations. The problem is exactly this, the glossy surface, it’s too slippy and Mr Bit tends to slide over it, at speeds any faster than the lowest we can go he goes skidding around in circles – which is funny but makes him a bit dizzy. We’re looking to get or make some sticky wheels to add to our change set of wheels for different challenges.

Comments 2

  1. Firat Dede

    Can you try with only 2 wheels design. 4 wheel will make harder turning. Plus if you have distance between sensors, wheels. Robot’s response time will catch and movements will be smoother. And sure with new SLT20 wheels will help to you too 🙂

    Overall I only think about if robot’s mechanical design can be better, all movements will be better I guess.. Lower COG, and try with different wheel to wheel distances.

    1. Post

      Thanks for the suggestions Firat. We will see how many of those things we can try though I think lowering COG will need a redesign.

      I like the 2 wheel idea not sure if we’ll be able to try that with this robot though.

      Going to give the SLT20’s a go which arrived today! 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *