Line Squaring for an EV3 Robot with Two Color Sensors

A line squaring program is a staple EV3 program to master for the FLL competition. I originally created line squaring for the 2013 FLL challenge, Nature's Fury, because I needed a program that would fix my robot's angle to 90 degrees to a line, as well as the robot's distance in one direction. Now, line squaring is one of my signature programs! The program allows a robot with two color sensors in front to align itself perpendicular to a horizontal line. In this week's EV3 programming tutorial, I teach you how you can write your very own line squaring program, as well as discuss the hardware requirements, so you can use it with your own FLL robot.
My Patreon supporters for more than $5 for the month of September were: Al Douglas, Stephen Rozmiarek and Turnabout Akamia. Thank you very much!
My supporters on Patreon contribute additional funding that allow me to build up and improve this channel and to make more videos. If you would like to help, you can support me here: / builderdude35
Special thanks to my friend Preston Nichols for designing Builderdude35's awesome new introduction and logo!
My Website: builderdude35.com/
Builderdude35 KZbin: / @builderdude35
Line Squaring: • Line Squaring for an E...

[@KeesLensvelt]

This is my 1st year as an FLL Coach, your site and your videos are like a paradise for me! Thanks for all your work!

[@Builderdude35]

Thank you! You're very welcome!

[@CyberSERT]

Outstanding tutorial. Thank you.

[@tanveep5478]

this is exactly what my team and i needed for reference! tysm!

[@Builderdude35]

You're welcome! I'm glad it is helping you. Good luck this year!

[@guopeneferozz]

Great work! Keep it going like this.

[@Builderdude35]

Thank you! I will.

[@dawencheng5423]

The line squaring program was not working at all for me, and I had it perfectly copied, except for different sensor values. But then I realized that the number of the degrees that the motor traveled was negative (measured by the motor sensor block), and I would only travel a negative amount of degrees because of that. I changed the divide by 2 in the math block to divide by -2, and it works perfectly now. If you people out there are having the same problem, change the divide by 2 in the math block to divide by -2. It should work now. Builderdude35, maybe you could edit the video and add a footnote that the math block should be divide by -2 instead of divide by 2 if positive power makes your robot go forward. Divide by 2 could work for Sirius and other robots that go forward with negative power, but it clearly does not work for my robot, which goes forward with positive power. Overall, still a great tutorial, and I would not have been able to line square without this program. Keep doing awesome tutorials, Builderdude35!!

[@Builderdude35]

Thanks for sharing, and yes, you are correct. If your robot drives forward with positive power, you must divide by -2. Unfortunately, KZbin took away Annotations so I can't add a note to the video. Thank you for pointing this out.

[@x-platform7460]

This is Ashton from team #3436, the Hydrators, of last year's Animal Allies winner. This code looks like it can really help us this year. The lack of usable immediate lines needs code similar to this to navigate the first bit of the table. Thanks for the help!

[@Builderdude35]

Awesome! I'm glad you're planning on making use of the program! Good luck this year!

[@mr.derpface]

very helpful

[@bravesquid6183]

YOU. ARE.GOOD.

[@Builderdude35]

Thanks!

[@Zander286]

Thanks

[@aayushgoyal9143]

I really appreciate yur hardwork and respect it.please try and make it with one sensor if (if)possible. Thanks

[@Builderdude35]

Thank you! Unfortunately, it's not possible to do this with one sensor. The reason boils down to geometry; two points define a line. The two sensors serve as the two control points necessary to straighten the robot out.

[@aayushgoyal9143]

thanks for the reply!

[@borjonx]

What if you used a motor to position the single sensor at position 1 when needed, and position 2 when needed?? Just thinkin' out loud here..

[@aayushgoyal9143]

jerry i think you are right

[@realtigeronline]

Nice job! (I just think when the motors keep spinning at 11:40 it sounds like the robot is choking xD)

[@Builderdude35]

Haha, that's an interesting observation!

[@firstnamelastname2888]

Hey, I saw this and it’s a huge help, but I followed the tutorial but I can’t get the program to work as the Color sensors and wheels are on opposite sides of my robot. Do you have any suggestions?

[@caoduynguyen2424]

Nice

[@Builderdude35]

Thank you!

[@soaydasilva6830]

hello bilderdute, i'm smithy, student of a fll robotics team from Mato grosso, Brazil. I publicized your programming demos and found it very interesting the way they did it all. Together with my team we request a video conference with your team to exchange information and help if you need the new season. We are available, We await return

[@veebhushah9667]

Can you please make something about advantages about different robots.

[@Builderdude35]

I will consider it. Thanks for the suggestion.

[@HexhamFoodCo]

Hi , I was watching one of your early vids with 4 wheel did drive. Can u recommend any programming to assist with wheel slippage going up a slope. Regards Paul, Hexham 3rd Guides

[@Builderdude35]

That is a touch one, I don't know if anyone has tried to tackle that yet. I would recommend you start researching the stability control systems used in real-world cars; they can detect wheel slippage and compensate. Then see what you can incorporate from there.

[@jonathanrachlin1455]

First, greatly appreciate your tutorials, we've learned so much from them. One question about your program -- in the video, the robot is always approaching from the same angle, in which the color sensor in the first loop reaches the black line first. This means that the other wheel hasn't reached the black line yet. However, if you approach from the opposite direction, the non-sensor wheel reaches the black line first, and if the angle is steep enough, goes past the black line by the time that the wheel on the sensor side reaches the line. Am I doing something wrong, or is this something that needs to be fixed? Many thanks!

[@Builderdude35]

Yes, you are absolutely correct! The right sensor is looking for the line first, so the robot can approach from a steeper angle from the right side. However, it cannot approach at much of an angle form the left side. You can always change which sensor is looking for the line first if you need to compensate for an approach angle from the other side. If you need it to be able to handle both sides, you need to use a switch block with multiple conditions; I have a tutorial on how to make those.

[@josephbastian3204]

You could modify the attack to look at the differential between either sensor.

[@christiangerlich2905]

Why do you use a loop-exit clause to read your sensor rather than a wait block with a sensor clause?

[@Builderdude35]

It's just habit. I'm used to programming in C, which has no such thing as a wait block/sensor clause (unless it's natural language). In C, you would set up a while loop with a condition, which in EV3-G is the equivalent of a Loop block with an exit case. You can certainly use a wait block/sensor clause, but I did it this way because that's how I'm used to programming in C. Great question!

[@christiangerlich2905]

Thanks, I was just wondering if this was perhaps more accurate. I think using the loop-within-loop structure could make ik more confusing, but your reasoning makes sense! to each his own I guess.

[@norad27]

My kids' team loves your tutorials. They have been stuck on squaring up for 8 months however because they made a robot that is rear-wheel drive with large motors backwards. They changed all the power to backwards but they can't get the line squaring to work. It always ends slightly angled They have 8cm from the center of the rear wheel to the color sensor and 14cm diagonally from the center of the pivot rear wheel to the center of the color sensor. The distance between their color sensors in front is 11.5cm.. I'm guessing the problems are because of the larger arc caused by the distance from the pivoting wheel to the color sensor. Can you give them some tips on what to modify when programming a rear-wheel drive design? I've seen suggestions about the geometry of a circle but the kids are confused about how to incorporate that. Thanks!

[@Builderdude35]

If the wheels are in the rear and the color sensors are in front, the increased distance between the wheels and the sensors will make for a longer arc of the color sensors when the wheels try to pivot the robot, as you said yourself. I recommend slowing everything in the program down (all motor speeds) to account for the extra sensitivity that the increased distance causes.

[@Zenglish000]

Good job. May I ask you something?My son is five years old , what can I do for him to be like you one day?Thanks and best of luck.

[@Builderdude35]

Fantastic question! Get him started with playing and building early. Start teaching him about mechanisms and whatnot. But most importantly, never force it on him; it should always be fun, play. That way, he'll enjoy it and come to love it on his own. All the best!

[@borjonx]

I wish I had a thousand mod points for this response. Do not demand learning it because you think it's important; they are not you. If they do get into it, they will thank you in 20 years because you got them started, you were patient & you encouraged them to experiment/explore.

[@KimEvenSong]

I would like to use a large motor for the steering (rack and pinion) of a truck I built. The range of that motor is just +/- 120 degrees. I would like to use a light sensor for a line follower program (proportional or even PID) that allows the truck to stay "on the road". Any suggestions to create the program with limited range of the (large) motor? Thank you for your ideas and expertise.

[@Builderdude35]

Sorry for not replying sooner! You can incorporate a switch that checks the motor's current amount of degrees. If it's > 120 (or < -120), have the robot power the motors back in the opposite direction. I recommend that you watch my four part series on programming car steering (Part 1: kzbin.info/www/bejne/mGeVYmCtbdJ3d7c). The videos are really old and kind of poor quality, but the information will help you a lot, as they cover exactly what you're trying to do.

[@KimEvenSong]

Thank you very much. My students and I will get right on it. Super stuff.

[@KimEvenSong]

How else could I access this 4 part series? My comp. cannot find that link. Thank you

[@Builderdude35]

Woops, that's my mistake. When I typed the comment, the parenthesis were included in the URL. Here's the correct link: kzbin.info/www/bejne/mGeVYmCtbdJ3d7c

[@neyum1555]

I have a question, my EV3 whenever I load it up to a project where its blah (testing) it doesn't seem to load on the EV3, I'm on the mobile version

[@Builderdude35]

I don't have any experience using the mobile version, so unfortunately I cannot offer any advice. Sorry!

[@neyum1555]

Builderdude35 okay all contact the devs and see if they know anything

[@dawencheng5423]

Also, my color sensors are sensing the edge of the black line during the program, and my robot just ends up being on the line, but not perpendicular. This is a correction to my previous comment: changing the math block thingamajig will help, but it will not make it perfect. The line squaring thing is not working at even moderately steep angles.

[@Builderdude35]

Thanks for the heads up. Maybe try changing your color sensor threshold values?

[@dawencheng5423]

Thanks, I did solve the problem. Part 2 of your original line squaring video series shows how to make a special My Block to improve the program, if you can recall. I combined that My Block and this new program and it is working great! Thank you as always!

[@Builderdude35]

You're welcome! I'm glad you solved the problem!

[@davidcrisafi3738]

Builderdude35, thanks for all these instructional videos. My daughter has benefited from your gyro videos this year. Re: line squaring ... we have done lots of studying, tried several approaches and even many of our own. best we get it "good" results ... say 80%, but there's always 20% or so (too high percent for us) where the robot is just not perfectly lined up at the conclusion and in fact, perfect is not the issue ... it's actually quite off. in your video above, at time mark 12:29 exactly, there is an example of exactly what I'm talking about re: the 20% not-so-good. that result is actually not square at all and while you may have clipped the video too short and that run ended perfectly, that is just an example of what i was talking about. we will try yours next. I originally stayed away because it just took a few too many seconds, but at this point, if the one outlined here is as good as it seems, we will just use it more sparingly. but, before we spend more time, i wondered if you had a suggestion to get around the issue i describe here.

[@Builderdude35]

The run at 12:29 ended up perfectly square, so I think it's just the camera angle making it look odd. If accuracy is your priority, I would highly recommend using this program; though it is time consuming, it is fairly reliable (though nothing is ever 100%). If the program as I show it in the video is still not accurate enough to suit your needs, try slowing it down or adding another repetition of the squaring.

[@realtigeronline]

David, can you please guide me on the gyro? or builderdude? It is measure angles up to 7000 degrees and constantly drifting...

[@4hrobotics220]

Having issues not getting it to work. it tries but then goes in a circle

[@Builderdude35]

The Color sensors aren't seeing the line because the target light values are incorrect. Measure the new target values using Port View and enter those into your program.

[@chainbreaker9079]

PLZzzzzz Help Me out can we do line squaring with one color sensor

[@Builderdude35]

No, two color sensors are required.

[@josephbastian3204]

could move the sensor to other side but that seems dicey

[@user-tp6uo2hw7q]

can i have the l dd file for this robot??!!!

[@veebhushah9667]

can you make a tutorial on clock work

[@Builderdude35]

Thanks for the suggestion, but that may be a little outside of my target content.

[@johanbijker7090]

Isn't it better to do left & right in parallel?

[@Builderdude35]

What do you mean by in parallel? Do you mean both wheels simultaneously?

[@johanbijker7090]

Yes - so both wheels move forward at the same time. Whichever one hits the line first must stop and wait until the second one hits the line.

[@Builderdude35]

Sure, it can be done that way, but you'll introduce extra motion that may make the squaring less accurate. Maybe there is no negative effect. Fixing each wheel individually allows the robot to focus on just one action at a time, which is the most accurate way to accomplish it. But, if you are in a crunch for time, squaring in parallel like you suggested is a great alternative. Maybe I'll make a tutorial on the topic!

[@sksdcemerlang9602]

IT NOT WORKING!!!!!!!!

[@TamNguyen-pg6wb]

Can you play football