Scioly.org

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.

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

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.

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.

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?

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.

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.