How to increase 3pi speed

Hello.

You should also note that the HP motors have a stall current of 1.6 A at 6 V and the TB6612 can deliver a maximum of 3 A per channel. The free-run current of the HP motors is below the 1 A continuous current rating of the driver, so a single TB6612 will work if you keep the voltage low (around 6V) and you keep the motors from stalling for prolonged periods of time or from suddenly changing from full-speed forward to full-speed reverse (this isn’t something that should happen when following a line).

As Jan said, we have used 3pis with HP motors on them, but we had to lower the boost voltage and take greater care when writing code to limit abrupt accelerations (PID usually does a good job of this when things are well tuned and a terrible job of this when they’re not).

Our latest Orangutan robot controller, the Orangutan SVP has two TB6612s in parallel, so it can deliver a continuous 2 A per channel (6 A max).

- Ben

Thanks Ben,

So, maybe I will order HP motors and try them first in 3PI as a first step, and then go from there.

BTW, how it is possible to change boost voltage? I don’t think there is potentiometer for this on 3pi. Would I have to resolder some resistor?

Thank you both,
Maris

Yes, you would have to swap out a resistor.

- Jan

Hi Jan and Ben,

Just wanted to asked a quick question. Can I used the 3pi library with the SVP1284?

jlake

Hello.

I don’t really understand your question. We offer the Pololu AVR library, which works with our Orangutan robot controllers and the 3pi robot. There are some 3pi-specific functions in this library, but you wouldn’t use these on the Orangutan SVP-1284.

- Ben

Ben,

Sorry for my previous post - what I mean was, there are some neat functions in 3pi - like this line sensing and etc. What I mean was - if I used the 3pi.h file in the SVP and used almost exactly the same code - can that run in SVP 1284? Or do I need to change some parts of it so it will work in SVP. Let’s take an example for the line sensor, in 3pi, we need to connect to the line sensor to PC0 and so on, where do I need to connect it in SVP and used the same code?

Hope I made it clear - if not, well, I am online now - I will try again,

jlake.

I don’t think there’s anything to be gained by trying to make the 3pi-specific code work on the SVP. Rather, I would just use the more general library functions. For example, the PololuQTRSensors section of the library provides code for interfacing with QTR sensors. The 3pi line sensor code just initializes a PololuQTRSensors object for the specific sensors on the 3pi. I think you should make your own initialization function for the number and type of sensors you have on the I/O lines you want to use. Does this make sense?

- Ben

Ben,

Thanks a lot.

Hi Ben,

I got your SVP-1284. I am just wondering where should i connect the QTR8RC. The sample code
unsigned char qtr_rc_pins[] = {14, 15, 16};

what pins is 14, 15 and 16? Is there a way for me to increase the number of pins?

Thanks again,

The QTR sensors section of the library command reference explains how to use the QTR functions (the documentation for the initialization function qtr_rc_init() is near the bottom of the page and answers the two questions you asked).

Note that we have added digital I/O support to the library since that example was written, so we now have some convenient constants you can use instead of pin numbers. The constants have the form IO_LN, where L is the port letter and N is the port number, so you would use the constant IO_C4 for pin C4 (see section 4 for more information). This makes it easier to write your pins array. Once you know what pins you want to use, you can make your array something like:

unsigned char qtr_rc_pins[] = {IO_D3, IO_D2, IO_D1, IO_D0, IO_C1, IO_C0, IO_B4, IO_B3};

- Ben

Hi jan,

Thanks a lot. Kind of weird thing on my SVP - I used this:

unsigned char qtr_rc_pins[] = {IO_D3, IO_D2, IO_D1, IO_D0, IO_C1, IO_C0, IO_B4, IO_B3};

but IO_C0 and IO_C1 will not work - it does not return any values. But when I changed the exact number of
IO_C0 and IO_C1 based on the previous 14 and 15 respectively - everything works fine. I guess i might have to change
something.

Anyhow, just one more quick thing - I wanted to used the encoder and line sensing at the same time, but when I tried to
initialize the encoder:
svp_set_mode(SVP_MODE_ENCODERS);
// reset encode counts
svp_get_counts_and_reset_ab();
svp_get_counts_and_reset_cd();

just right after the line sensor calibration - PB4 stops working. Is PB4 connected to the encoder?

Thanks again.

It looks like we never updated the QTR sensor library for the Orangutan SVP and Orangutan X2, which is why you’re having problems with the IO_Cx macros from OrangutanDigital (since OrangutanDigital has been updated for the SVP). Unfortunately, you won’t be able to use the IO_Ax pins with the QTR sensor library until we update it.

Your problem with PB4 is that it is the slave-select line of the SPI module, so there are restrictions on its use when you are communicating with the auxiliary MCU (as happens when you try to read the encoders). The SPI module will only work in master mode if PB4 is an input that reads high (the Pololu AVR library configures it as a input with the internal pull-up enabled once the SPI module is initialized) or if it is an output. You should be able to alternate reading the encoders and QTR sensors by manually configuring PB4 as an output when you want to use SPI and as an input with internal pull-up disabled when you want to read the sensors.

- Ben

Hi Ben,

Thanks for the prompt reply. Anyhow, with regards to the line sensing and encoder - I guess I might find some means to compute the speed of the robot. Does this mean that I cannot used the USB capability of SVP if I will used the line sensor?

Pin PB4 will affect all communication between the user MCU (ATmega1284) and the auxiliary MCU, so if you want to use PB4 for the line sensor, you will need to manually configure the state of PB4 as is appropriate for whatever action you are trying to perform (i.e. set it as an output or pulled-up input when using SPI). If you set it as a pulled-up input, you should delay for a few milliseconds to let the voltage rise and stabilize before you try using SPI. You could also just use seven of the eight reflectance sensors and leave pin PB4 free, or you could to add support for port A pins to the QTR library source code (if you don’t want to wait for us to do it).

- Ben

I did some experiments. It turns out that PB4 can not be used as a digital input while the SPI module is enabled (PINB bit 4 is always 0). We already knew that using PB4 as a digital input could cause the SPI module to fail (that’s why the SVP user’s guide says that we recommend making PB4 an output), but we didn’t know that SPI causes digital input to fail. If you really want to use PB4 as an input, you can temporarily disable the SPI module (by clearing the SPE bit in SPCR).

So jlake, if you want to get all 8 of your QTR sensors working right now, I suggest adding code around your QTR-reading code like this:

unsigned char saved_spcr = SPCR;   // Save the state of the SPI module
SPCR &= ~(1<<SPE);                 // Disable SPI module so PB4 can be used as input
qtr_read(values, QTR_EMITTERS_ON); // change this to whatever type of QTR reading you want to do
set_digital_output(IO_B4, LOW);    // Make PB4 an output so it doesn't interfere with SPI.
SPCR = saved_spcr;                 // Restore the state of the SPI module.

This code worked for me, allowing me to read analog channel A from the auxiliary processor via SPI and also read a QTR-RC sensor on PB4 in the same program. This code also works if you drive PB4 high instead of low, but that would cause increased power consumption.

Also, later today we should have a new version of the Pololu AVR Library out that allows you to use pins A0-A7 for your sensors, so you won’t have to deal with the quirks of PB4. When we release it, we’ll make an announcement in the announcements forum.

–David

I didn’t manage to officially release the new AVR library and update the documentation today, but I have made the new version available for you to download at this link:

pololu.com/file/0J380/libpol … 100604.zip

That should let you put QTR sensors on port A using the IO_A0…IO_A7 macros, so there is no need to try to get them working on PB4. Enjoy!

-David

Hi david and Ben,

Thanks for the reply. Anyways, I am using QTR-RC sensors - can I still used the IO_A0 on this sensor or do I need to but the other line sensor you have?

Thanks again,

Hi David,

If so that I can used the QTR-RC in the analog pin - then I might have some problems - since I will be using at least 4 analog pins for my other sensors. What I have done so far were these:

I managed to used only 5 line sensors:
unsigned char qtr_rc_pins[] = {11, 14, 15, 0, 1}; // I tried to get rid of PB4 as I need the serial port at UART1
Used UART1 as my wireless tx/rx to my PC
serial_set_baud_rate(UART1, 9600); // using UART1
serial_receive_ring(UART1, receive_buffer, sizeof(receive_buffer));

I tested the serial - works perfectly. But when I tried to run the robot - it’s kind of weird - one motor is not running the way it used to be - and I guess it still have problems even when I tried not to used the PB4.

what did I miss?

I’m not saying that you should put all of your QTR-RC sensors on port A (the analog port). You can have some of them on port A and some of them other ports, according to what you need.

Pin numbers 14-20 have a different definition on the SVP (and X2) than they do on our other devices, so to make your code clear you should use the IO_* macros. For example: { IO_B3, IO_C0, IO_C1, IO_D0, IO_D1 }. Also have you downloaded and installed the new version of the Pololu AVR Library I linked to in my last post? You should do that so that the PololuQTRSensors section of the library interprets those new pin numbers correctly. After you do that, you should be able to use all 8 of your QTR sensors if you want to and you have enough free pins.

Also, why do you think that PB4 is related to UART1? As far as I know, PB4 is related to SPI, but not UART1. Do we have any documentation that mistakenly says that PB4 is related to UART1? If so, you should tell us where that documentation is so we can fix it.

Great!

What are the differences between the program that previously worked and the program that doesn’t work now? Can you load the previously-working program on the SVP and see if it sill works? Which version of the Pololu AVR Library are you using? Can you simplify your program and post the simplest possible program that doesn’t work, and describe the expected behavior and actual behavior?

-David

Hi Dave,

The only difference for the working code was that I used PB4 on it and now I used:

PB3, PC0, PC1, PD0, PD1

I checked each of the sensor on this new pin connections and it reported correct readings. But when I started to run the robot - it veers to the left and somehow lost it orientation.

So I put the PB4 back and get commented my serial initialization and it works perfectly.

Previously used ports was: PB3, PB4, PC0, PC1 PD0.