Spending time with the guys at Officine Robotiche (a huge thank to Stefano Artigianato Robotico), i’ve discovered the world of line followers. Apparently simple robots whose ultimate goal is to, guess what, follow a line 🙂
This simple task involves several issues:
- reading sensors to determine the line displacement;
- employing a control algorithm to determine the movement vector;
- motor control;
- several other ancillary stuffs, like telemetry, etc;
Obviously mine will run LibrePilot 🙂 and that simplifies a lot of things as most of the component needed are either in place or needs minor rework.
Unfortunately I had no enough time to make a custom board so I went for some ready stuffs for sensor board and motor driver. Thanks to Stefano’s suggestions and after fiddling with their datasheets I ended with the following component list:
- 1:30 gearmotor https://www.pololu.com/product/2212
- DRV8833 dual motor driver https://www.pololu.com/product/2130
- QTR-8RC Reflectance Sensor Array https://www.pololu.com/product/961
- 12mm hex wheel adapters https://www.pololu.com/product/2682
- soft foam 1:12 RC Car wheels bought at a local store (yes, the ones with real people you can talk to 🙂 )
It will be based on OpenPilot Revolution board given it has plenty of I/O and RF module onboard, useful for tuning and telemetry.
I’ve also left some mounting holes that may host a NanoPI neo. One day it will be used for optical recognition for, i.e. better line speed planning.
This is the frame I made for this robot
It is made of two parts, the main frame structure and sensor housing. It is available for download at Thingiverse (http://www.thingiverse.com/thing:1792422)
I used PETG for the main part and PLA (that is hard and have very low friction).
And here is a short video of the thing moving for the first time, using a standard RC transmitter (and related receiver) for control. It is already using gyro for yaw/trajectory stabilization
There is still a big to do list ahead, including (but not limited to) reversable motors handling and sensor reading.
LibrePilot had already almost everything needed. I added a specific target ( i called that roborevolution based on the revolution target, employing several changes needed to manage brushed motors and all the sensors needed). To have this first test working i only had to tweak the Servo motor drivers to handle higher frequencies and to increase the available resolution.
edit: here is the, still very hacky. source code i’m working on https://github.com/AlessioMorale/LibrePilot/tree/amorale/linefollower
edit2: and it works 🙂 until i find some time for a new update post, here are two videos of its first tests
…after a bit of tuning 🙂
If you know a little bit of OpenPilot history you understand it was more about when, not “if”. After a little less than 4 years of contributions to the OpenPilot project it was time to part.
Just to give a bit of context, I started with OP at the beginning of 2012, working at the early stage of the revolution firmware and hardware development. I mostly took care of the bare metal firmware side, sensors and peripherals interfaces, porting the code to various targets (i.e. STM32 F0 for GPS V9, STM32F411 for nano Nano). I‘ve also participated in hardware development/validation and testing since the initial Revolution prototypes (not the small officially sold, but the previous bigger brother http://wp.me/p1tDhc-2H ) . I’ve worked at flight performances improvement with mini quads for CC3D/Revo (the thing that, together with the acro+ develiped by Eric/CorvusCorax, made CC3D so popular in the 250 class racers) , implemented OneShot, notification smart leds support, a new sensor framework implementation and several other things.
Later I’ll have to write some detailed chronological history of the awful situations, the falsification and everything else happened in the last 1 and 1/2 months that brought me, most of the development team and several key members to build a new project (LibrePilot) from the roots of OpenPilot.
One question that i have been asked several time is: wouldn’t be better to join to an existing project, like TauLabs?
This was actually one of the possibilities, the fact is that we are already a solid, very well proven team and this may have caused “integration” issues.
But the intentions are to collaborate with other projects, especially TauLabs. Probably one of the best (long term) bets for both projects is to converge to a single codebase that takes the best of both worlds. Unfortunately it is a quite demanding task as in the last couple of years they have diverged a lot, but surely it will worth the effort, both in term of features/quality than in term of critical mass of users and development team.