Electric Vehicle C

Locked
User avatar
UQOnyx
Exalted Member
Exalted Member
Posts: 274
Joined: November 28th, 2012, 2:23 pm
Division: C
State: NJ
Has thanked: 0
Been thanked: 0

Re: Electric Vehicle C

Post by UQOnyx » December 28th, 2015, 4:37 pm

FawnOnyx wrote:
UQOnyx wrote:I figured out the root to all of my problems... and it kinda sucks until I can find or make better code. Basically my code was perfectly fine... However, my encoders aren't perfect. When the code sets a speed above a certain threshhold, I think that the encoders begin to freak out (probably because of their resolution) and cycle between random increments. So for now, in order to practice, all we have to do is set the speed of the motors to a lower setting.
In your encoder handling code, are you using interrupts to detect rising edges from the encoder pins? If not, I suspect the reason you can't accurately track high speeds is that your control loop doesn't run fast enough to catch all the rising edges. The control loop frequency should be the bottleneck far sooner than anything mechanical or electrical in the encoder because the control loop likely has hundreds of instructions (clock cycles) to go through each time, whereas most quadrature encoders' outputs are asynchronous and really fast.

For example, if one has a motor running at 6000 RPM or 100 rotations per second and the encoder has 100 pulses per rotation, there are 10,000 pulses per second (10kHz) that the microcontroller must detect perfectly. With a typical Arduino running at 16Mhz, this means that one can fit (very roughly) 1,600 processor instructions maximum per control loop before expecting losses. Keep in mind that 1 line of C++ can translate into many processor instructions after compilation. This post suggests that Arduino's digitalWrite and digitalRead take around 50 clock cycles each (the convenience of the functions comes with the cost of considerable overhead). Also, the period of the 10kHz encoder pulses is 1/10000=0.1 ms, so if you have any sort of delay() calls that stall the control loop on the order of milliseconds, you can abandon any hope of tracking the encoder accurately. (instead of delay, look at millis() or micros())

One can do the math in a more indirect way too: If you want the car to go 5 m/s but want your encoder configured to have 1mm resolution (1mm per pulse), then at max speed, the encoder will be sending 5/0.001=5000 pulses per second. This translates to 3,200 clock cycles max or a period of 0.2ms.

The best solution that should guarantee accuracy is to use interrupts to track the encoder pulses. The link has more detailed info, but basically an interrupt enables dedicated electronics to listen for a rising edge (or other types) on a certain pin and literally interrupt whatever the arduino was doing and enter a function of your choice before returning back to what it was doing. In the case of encoder reading, this function probably checks if it should increment or decrement an encoder position variable. The advantage is that interrupts trigger exactly when you want them to and get out of the way of your control loop otherwise.

Since interrupts rely on special electronics, only two of the pins on a typical Arduino are interrupt capable. Fortunately, quadrature encoders only have two wires to listen to, so it works out. I would also suggest looking at this encoder library which is optimized for interrupts, saves you some work writing the code, and would probably be more reliable anyway. I've used it before for a simple knob but I think it'd work well for this high speed stuff.

Sorry this went went so in-depth, and maybe you're already using interrupts. Nevertheless, I think it's interesting and I hope it's helpful to others.
Update: All code problems have been solved!

Thanks for the great reply. I, in fact, was already using an interrupt function :D , but I reached the same conclusion for the same reason as what you wrote. I initially tried using the quadrature encoders using a basic function running in the main void loop () function, but this was extremely limiting for my motors for a multitude of reasons. Basically it was just sloppy code. Then, I switched over to using the interrupt pins (thanks to google and arduino tutorials), and it solved most of my problems. However, like I said in my previous post, the motor speed was limited by the quadrature's readings... Very weird. After about a full hour of debugging and even consulting my dad (he's a technical software architect), I still couldn't isolate the cause to the symptoms.

Heres the AHA! moment. Today I met up with my partner, and I just explained and re-hashed everything again for his benefit. And then suddenly I realized... I'm trying to loosen a bottleneck! What bigger bottleneck is possible than a serial stream of packets of data going through a USB?? So, in a stroke of inspiration, I just erased all of the serial functions that output to the serial monitor... Lo and behold, it worked like a charm! I could set motors to go at max RPM, and the quadrature could keep track of the movements, which was evident by the motor's output- the motors stopped after a certain number of turns. Perfect!!!

So now, all that is left is calibration, testing, and buying a new set of wheel hubs. Thanks for the help folks!
Noor-ul-Iman School

2012 Events:
Forestry
Storm The Castle


2013 Events:
Boomilever
Shock Value
Forestry


I know the voices aren't real, but they have some great ideas..

iwonder
Admin Emeritus
Admin Emeritus
Posts: 1112
Joined: May 10th, 2011, 8:25 pm
Division: Grad
State: TX
Has thanked: 0
Been thanked: 0

Re: Electric Vehicle C

Post by iwonder » December 30th, 2015, 6:25 pm

That's awesome!

Soon you'll discover the joys of on chip debugging and dive even deeper into the rabbit hole :P
'If you're the smartest person in the room, you're in the wrong room' - Unknown

cifutielu
Member
Member
Posts: 63
Joined: March 2nd, 2013, 9:38 pm
Division: C
State: IL
Has thanked: 0
Been thanked: 0

Re: Electric Vehicle C

Post by cifutielu » January 11th, 2016, 10:59 am

So my design is powered through a Raspberry Pi and a Python program.

Would I be allowed to start the vehicle by pressing a button on a keyboard that is outside the vehicle? Or does the button that is pressed have to lie on the vehicle itself?

Also, in the rules, what does it mean by the vehicle cannot be remotely tethered? Would I not be able to bring a laptop to access my Python program on my vehicle (powered by a Raspberry Pi) and start it? If not, would it be within the rules to attach a screen to my vehicle to see my Python program and start the vehicle with a wireless keyboard?

Thanks

A Person
Member
Member
Posts: 185
Joined: July 18th, 2010, 12:34 pm
Division: Grad
State: KY
Has thanked: 0
Been thanked: 0

Re: Electric Vehicle C

Post by A Person » January 11th, 2016, 11:18 am

cifutielu wrote:So my design is powered through a Raspberry Pi and a Python program.

Would I be allowed to start the vehicle by pressing a button on a keyboard that is outside the vehicle? Or does the button that is pressed have to lie on the vehicle itself?

Also, in the rules, what does it mean by the vehicle cannot be remotely tethered? Would I not be able to bring a laptop to access my Python program on my vehicle (powered by a Raspberry Pi) and start it? If not, would it be within the rules to attach a screen to my vehicle to see my Python program and start the vehicle with a wireless keyboard?

Thanks
Probably on the vehicle itself. First off, you're not supposed to have any wires and such trailing behind. Second, that might be considered a remote controlled vehicle, leading to a building violation.

Section 2.k. "The vehicle must not be remotely controlled or tethered."

You should be able to start the Python program through a USB, unplug it, then use another button on the (untethered) car to activate it. For example, start a program that says "when button is pressed, run motor" or something like that.
"Any sufficiently advanced technology is indistinguishable from magic." - Arthur C. Clarke

User avatar
InfiniCuber
Member
Member
Posts: 171
Joined: October 20th, 2012, 6:15 am
Division: C
State: IN
Has thanked: 0
Been thanked: 0

Re: Electric Vehicle C

Post by InfiniCuber » January 11th, 2016, 11:24 am

A Person wrote:
cifutielu wrote:So my design is powered through a Raspberry Pi and a Python program.

Would I be allowed to start the vehicle by pressing a button on a keyboard that is outside the vehicle? Or does the button that is pressed have to lie on the vehicle itself?

Also, in the rules, what does it mean by the vehicle cannot be remotely tethered? Would I not be able to bring a laptop to access my Python program on my vehicle (powered by a Raspberry Pi) and start it? If not, would it be within the rules to attach a screen to my vehicle to see my Python program and start the vehicle with a wireless keyboard?

Thanks
Probably on the vehicle itself. First off, you're not supposed to have any wires and such trailing behind. Second, that might be considered a remote controlled vehicle, leading to a building violation.

Section 2.k. "The vehicle must not be remotely controlled or tethered."

You should be able to start the Python program through a USB, unplug it, then use another button on the (untethered) car to activate it. For example, start a program that says "when button is pressed, run motor" or something like that.
That's exactly what I was thinking...

cifutielu, let me ask you this. when you press the button on your keyboard, is the device on your vehicle still plugged in? If so, how do you plan on dragging said keyboard with the vehicle? Trying to unplug in between pushing a button on a keyboard and the release of the car wouldn't be allowed. I would do what A Person said, and as virtually everyone else has done and just upload your program to the Pi and wire a button to it that activates said program. If you REALLY wanted to I suppose you could put a screen with a keyboard on the vehicle (wireless keyboard would be against rule 2.k.) but why do that when you can just add a button.

This sort of thing with a button works much easier with an Arduino , be it an Uno or Mega etc.Those have buttons built in that reset and run whatever program is on them.
Scioly isn't a club, or an organization. It is a lifestyle.
~Munster High School Science Olympiad Captain 2016~

cifutielu
Member
Member
Posts: 63
Joined: March 2nd, 2013, 9:38 pm
Division: C
State: IL
Has thanked: 0
Been thanked: 0

Re: Electric Vehicle C

Post by cifutielu » January 11th, 2016, 12:02 pm

InfiniCuber wrote:
A Person wrote:
cifutielu wrote:So my design is powered through a Raspberry Pi and a Python program.

Would I be allowed to start the vehicle by pressing a button on a keyboard that is outside the vehicle? Or does the button that is pressed have to lie on the vehicle itself?

Also, in the rules, what does it mean by the vehicle cannot be remotely tethered? Would I not be able to bring a laptop to access my Python program on my vehicle (powered by a Raspberry Pi) and start it? If not, would it be within the rules to attach a screen to my vehicle to see my Python program and start the vehicle with a wireless keyboard?

Thanks
Probably on the vehicle itself. First off, you're not supposed to have any wires and such trailing behind. Second, that might be considered a remote controlled vehicle, leading to a building violation.

Section 2.k. "The vehicle must not be remotely controlled or tethered."

You should be able to start the Python program through a USB, unplug it, then use another button on the (untethered) car to activate it. For example, start a program that says "when button is pressed, run motor" or something like that.
That's exactly what I was thinking...

cifutielu, let me ask you this. when you press the button on your keyboard, is the device on your vehicle still plugged in? If so, how do you plan on dragging said keyboard with the vehicle? Trying to unplug in between pushing a button on a keyboard and the release of the car wouldn't be allowed. I would do what A Person said, and as virtually everyone else has done and just upload your program to the Pi and wire a button to it that activates said program. If you REALLY wanted to I suppose you could put a screen with a keyboard on the vehicle (wireless keyboard would be against rule 2.k.) but why do that when you can just add a button.

This sort of thing with a button works much easier with an Arduino , be it an Uno or Mega etc.Those have buttons built in that reset and run whatever program is on them.
The keyboard is wireless already, but yeah, it might be a rule violation.

Would I still be allowed to type in the distance the car should go into the program, then disconnect the screen and keyboard before starting it with a button on the vehicle?

User avatar
InfiniCuber
Member
Member
Posts: 171
Joined: October 20th, 2012, 6:15 am
Division: C
State: IN
Has thanked: 0
Been thanked: 0

Re: Electric Vehicle C

Post by InfiniCuber » January 11th, 2016, 12:17 pm

cifutielu wrote:
InfiniCuber wrote:
A Person wrote: Probably on the vehicle itself. First off, you're not supposed to have any wires and such trailing behind. Second, that might be considered a remote controlled vehicle, leading to a building violation.

Section 2.k. "The vehicle must not be remotely controlled or tethered."

You should be able to start the Python program through a USB, unplug it, then use another button on the (untethered) car to activate it. For example, start a program that says "when button is pressed, run motor" or something like that.
That's exactly what I was thinking...

cifutielu, let me ask you this. when you press the button on your keyboard, is the device on your vehicle still plugged in? If so, how do you plan on dragging said keyboard with the vehicle? Trying to unplug in between pushing a button on a keyboard and the release of the car wouldn't be allowed. I would do what A Person said, and as virtually everyone else has done and just upload your program to the Pi and wire a button to it that activates said program. If you REALLY wanted to I suppose you could put a screen with a keyboard on the vehicle (wireless keyboard would be against rule 2.k.) but why do that when you can just add a button.

This sort of thing with a button works much easier with an Arduino , be it an Uno or Mega etc.Those have buttons built in that reset and run whatever program is on them.
The keyboard is wireless already, but yeah, it might be a rule violation.

Would I still be allowed to type in the distance the car should go into the program, then disconnect the screen and keyboard before starting it with a button on the vehicle?
Yes, that is what many people do, including myself. As long as you can't control the code after the launch, you should be good. Don't risk the violation, they WILL dock you on that!
Scioly isn't a club, or an organization. It is a lifestyle.
~Munster High School Science Olympiad Captain 2016~

User avatar
Bazinga+
Exalted Member
Exalted Member
Posts: 383
Joined: March 8th, 2014, 7:10 am
Division: C
State: NY
Location: Ward Melville HD
Has thanked: 0
Been thanked: 0

Re: Electric Vehicle C

Post by Bazinga+ » January 16th, 2016, 3:23 am

Rule 4 d. States that no part of the vehicle must start more than 1 meter behind the starting line. Is the dowel of the vehicle required to start on the starting point? I originally thought that it had to start on the starting point by definition, but this rule makes me doubt it since I don't know why they would need it if the length limit is well under a meter.
Innovation =/= success

User avatar
windu34
Staff Emeritus
Staff Emeritus
Posts: 1364
Joined: April 19th, 2015, 6:37 pm
Division: Grad
State: FL
Location: Gainesville, Florida
Has thanked: 1 time
Been thanked: 22 times

Re: Electric Vehicle C

Post by windu34 » January 16th, 2016, 7:02 am

Bazinga+ wrote:Rule 4 d. States that no part of the vehicle must start more than 1 meter behind the starting line. Is the dowel of the vehicle required to start on the starting point? I originally thought that it had to start on the starting point by definition, but this rule makes me doubt it since I don't know why they would need it if the length limit is well under a meter.
That's interesting...I hadn't picked that up. it would certainly help time scores. Submit an official clarification on sonic.
Boca Raton Community High School Alumni
Florida Science Olympiad Board of Directors
National Physical Sciences Rules Committee Member
kevin@floridascienceolympiad.org || windu34's Userpage

chalker
Member
Member
Posts: 2106
Joined: January 9th, 2009, 7:30 pm
Division: Grad
State: OH
Has thanked: 1 time
Been thanked: 52 times

Re: Electric Vehicle C

Post by chalker » January 16th, 2016, 12:56 pm

Bazinga+ wrote:Rule 4 d. States that no part of the vehicle must start more than 1 meter behind the starting line. Is the dowel of the vehicle required to start on the starting point? I originally thought that it had to start on the starting point by definition, but this rule makes me doubt it since I don't know why they would need it if the length limit is well under a meter.
I'm not seeing anything in the rules that says anything about the dowel needing to be on the starting point......not sure why you would assume that.

Student Alumni
National Event Supervisor
National Physical Sciences Rules Committee Chair

Locked

Return to “Electric Vehicle C”

Who is online

Users browsing this forum: No registered users and 1 guest