amano001: Initially you said you were using CR servos, but your latest posts talk about a 4-channel DC motor controller. Which are you using?
You can read Duane's love/hate relationship with the Rover 5 chassis in several of his threads. Looks neat, but pretty flexible, which may cause problems once the weight of the vehicle creeps up. Especially since mecanum wheels push & pull your wheels in all directions. Looks like your bot is getting heavy, so you might consider a different chassis. Even a hunk of plywood! http://www.youtube.com/watch?v=rAgiYtwuWB4
BTW, I'm a staunch advocate of slow, torquey DC motors with lots of gear reduction, because they will be pretty closely matched, RPM-wise. I've had good results with my simple mecanum bot, which doesn't even have encoders yet: http://www.youtube.com/watch?v=RPIfIOat6Os
I want to point out I was wrong about the 5V regulator. The Propeller Proto Board does indeed have a 5V regulator.
I know I was thinking to myself as I clicked the link "I'd use a QuickStart of a Propeller Project Board if I were amano001." When the board wasn't a QuickStart my brain hallucinated a Project Board (it's the same size as a Proto Board). (Don't tell anyone about my hallucination, it's kind of embarrassing. Especially not erco!)
The reason I'd suggest the Project Board over the Proto Board is the Proto Board requires a Prop Plug to program it. There are lots of Propeller board that require a Prop Plug for programming but if you're only purchasing one board then a board with built in USB makes more sense. Both the QuickStart and the Propeller Project Board have on board USB and can be powered by the USB connection.
Here's a regulator I use when I need 5V on a robot.
I agree with erco about your robot starting to look a bit on the heavy side. One thing that might help is the use of a higher voltage battery pack. I originally used a 2 cell LiPo to power my robot but I had so many more 3 cell LiPos (used with my quadcopters) that I started using a 3 cell with this robot. The 12 Volts (probably dropped to 10V after the motor controller) is higher than the motors 7.2 volt rating but it's nice to have the extra power. I figure I'm shortening the life of the motors but I don't run the robot for very long when I use it so I thought risk wasn't too bad.
Hey guys, THanks for all the info. I think I definetely WIll go the way of slaving out the board. That way I can use the arduino to deal with ultrasonics making sure the robot stays parallel to the wall. I have a quickstart board I bought for myself originally to play with and then I ordered the board with the 5v regulator but im starting to rethink my purchase since we just going to use it as a slave board. Also I already have a FTDI connector from an arduino I built myself from a kit, so I dont have to worry about getting the prop clip.
The previous robot we had built was using servos but now we switched over to the rover 5 chassis w/ motors because the shafts were starting to bend and cause slow down. The robot is a little heavy with the arm we wired up 2 in parallel 7.2v Nicad batteries for power and then we break down that power with 2 different 5v regulators for different parts. Running it off the board itself was just making it easier and less wires going everywhere but if we have to we will just add another temrinal block to run the servos and sensors off of.
Thanks for the info on the 3.3 logic we just wanted to make sure before we blew something up lol.
I am looking over your code now that you have uploaded, We are very short on time so it will be a lifesaver to not have to learn the propeller stuff right away and just use it as an integrated part of our robot.
Thanks and I will keep you updated on how things are going, the computer vision is a pain in itself.
Also wanted to ask you our logic behind making sure the robot is parallel with wall is using 2 ultraonics one on each corner and determining the distance they are off by parallel being u1-u2 = 0 if they are the same distance from the wall therefore they are parallel. If u1-u2 <0 means left side of robot is going faster then right side and opposite case for u1-u2 >0 . Do you think this is overthinking the process? We need to be very precise when the robot moves into positions on a board.
I am having a horribly hard time getting this to work lol. I can't seem to figure out how to program which pins are going where from the motor controller. Enc 1 = A and B signals and ENC 2 = A and B Signals I put into pins3 and 4 on my parallax and I get a static changing value so if I spin the wheel forward it counts up and reverse counts down which seems to be working I think but I never set any pins unless 3 and 4 are defaults pins for the encoder[1]. I cant seem to find where to set the motors pwm pins either.
Let me know if your available for a skype pow wow, my skype is mayong972
I am having a horribly hard time getting this to work lol. I can't seem to figure out how to program which pins are going where from the motor controller. Enc 1 = A and B signals and ENC 2 = A and B Signals I put into pins3 and 4 on my parallax and I get a static changing value so if I spin the wheel forward it counts up and reverse counts down which seems to be working I think but I never set any pins unless 3 and 4 are defaults pins for the encoder[1]. I cant seem to find where to set the motors pwm pins either.
Let me know if your available for a skype pow wow, my skype is mayong972
I have a bunch of instructions in the top object "Demo4WDBot13026e.spin".
Here's the section about setting encoder and motor pins:
******* Setup Instructions *******
This object is intended to be easy to use with multiple
robots.
The settings for a specific robot are held in a "Header"
file. This file should be modified to reflect the
setup of each robot.
******* Motor/Encoder Setup *******
The pins used to control the motors, and those used
to receive encoder pulses, should be set in the header
file.
The motors/encoders are numbered starting with
zero in the front left, motor #1 is in the front
right, motor #2 is in the rear left and motor #3
is in the rear right of the robot.
Any free I/O pin may be used to control the motors.
The direction the motor turns may be adjusted
by switching "WHEEL_RED_x" and "WHEEL_BLACK_x" constants.
The quadrature encoder pins need to be grouped together
in pairs. Each quadrature encoder output should be
connected to two consecutive I/O pins. The order of the
two pins within the pair is not important. The direction
sensed by the encoders may be adjusted with the
"FORWARDx" constants.
The pin settings are in the file "HeaderMecanumQs_130226a.spin".
Here's the section:
WHEEL_RED_0 = 17 ' The "RED" constants don't have to be assigned to WHEEL_BLACK_0 = 18 ' red wires. It may be useful to switch the pin
WHEEL_RED_1 = 21 ' assignments if the wheel direction doesn't match
WHEEL_BLACK_1 = 20 ' the encoder directions.
WHEEL_RED_2 = 23 ' Set to "-1" if a motor isn't being used.
WHEEL_BLACK_2 = 24 ' If any of the three motor control pins is
WHEEL_RED_3 = 27 '26 ' is set to -1, the motor will not receive a PWM
WHEEL_BLACK_3 = 26 '27 ' signal.
FIRST_ENCODER_0 = 0 ' The next I/O pin higher will also be used.
FIRST_ENCODER_1 = 2 ' Example: the encoder for motor #1 will use pins 2 and 3.
FIRST_ENCODER_2 = 4 ' Set to "-1" if a motor isn't being used.
FIRST_ENCODER_3 = 6
WHEEL_ENABLE_0 = 16
WHEEL_ENABLE_1 = 19
WHEEL_ENABLE_2 = 22
WHEEL_ENABLE_3 = 25
The constant "WHEEL_RED_0" should be set to one of the two pins that control the front left motor. On my motor control PCB it's marked "IN1". "WHEEL_BLACK_0" connects to the other motor controller pin ("IN2" on my board).
Don't worry about which way the motors spin to start with. You'll want to get the encoder directions figured out first and then come back and set the motor pins so they agree with the encoders.
I've made it so you don't have to switch encoder wires or motor wires if you don't want to. The directions of both the encoders and motors can be set with the constants in the header file. Depending on your setup, it might be easier just to switch wires rather than changing constant values.
During this initial setup phase, you'll want to make sure the line"INPUT_TYPE = PC_ONLY_INPUT" is not commented out. Here's the section of code to look for.
' inputType enumeration #0, PC_ONLY_INPUT, WII_NUNCHUCK_INPUT, RC_INPUT, WII_AND_RC_INPUT, AUTO_DETECT_INPUT
INPUT_TYPE = PC_ONLY_INPUT '' Use this when first setting up robot
'INPUT_TYPE = WII_NUNCHUCK_INPUT
'INPUT_TYPE = RC_INPUT
'INPUT_TYPE = WII_AND_RC_INPUT '' Not yet supported. If used it will behave the same
'' as AUTO_DETECT_INPUT.
'INPUT_TYPE = AUTO_DETECT_INPUT '' Priority given to Nunchuck
You shouldn't need to change this since the appropriate line is already active.
I did notice a section of code in the header with an incorrect setting.
' wheelMode enumeration #0, INDEPENDENT_WHEELS, TREADED_WHEELS, MECANUM_WHEELS
'WHEEL_MODE = INDEPENDENT_WHEELS '' Use this when first setting up robot
WHEEL_MODE = TREADED_WHEELS '' The target speeds of each side will be matched.
'WHEEL_MODE = MECANUM_WHEELS
I'm not sure why I had the active mode set as "WHEEL_MODE = TREADED_WHEELS".
While you're setting up your robot, you should change the above code to:
' wheelMode enumeration #0, INDEPENDENT_WHEELS, TREADED_WHEELS, MECANUM_WHEELS
WHEEL_MODE = INDEPENDENT_WHEELS '' Use this when first setting up robot
'WHEEL_MODE = TREADED_WHEELS '' The target speeds of each side will be matched.
'WHEEL_MODE = MECANUM_WHEELS
This will let you control the speed of each motor independently from the rest of the motors. You'll probably want to keep it set to "INDEPENDENT_WHEELS" when you're sending it instructions from your other microcontroller.
While you're in the header file, you'll want to set "PROPORTIONAL_CONSTANT" to zero while you're setting up the motor and encoders. This will keep the motors from spinning at full speed if the encoders' directions don't match the motors' directions.
You'll want to make sure and use resistors between the Rover 5's encoders and Propeller's I/O pins.
******* Note About Wiring *******
Each encoder pair needs to be connected to two consecutive
Propeller pins.
10KΩ resistors should be used in series with the encoders.
10KΩ series resistors should also be used if a RC
receiver is used.
If a Wii Nunchuck is used, it is expected to be used
on the Prop's I2C bus (P28 & P 29).
Once you have the above constants all set, you'll want to load the top object "Demo4WDBot130226e" into your Propeller board's EEPROM (by pressing "F11").
Open the Parallax Serial Terminal (by pressing F12). With the baud set to 115,200 and with the appropriate comm port selected, you should see a bunch of data in the terminal window.
You'll want to pay attention to the "currentSpeed" values. Turning the wheels in the direction that would cause the robot to move forward should produce positive speed. If the speed is negative, then you'll want to do one of two things.
If you're encoder pins are easy to switch, just switch the two encoder pins for that particular wheel. The other way to deal with a negative speed with positive wheel motion is to change the constants "FORWARD0" through "FORWARD3". Change the constant that corresponds to wheel from "1" to "-1".
Once all the "currentSpeed" values give positive speed with forward robot motion, you'll want to make sure the motors' directions match the encoder directions. There's no guarantee which way the motors will turn when power is applied to the red and black wires. Some of these wires are reversed when they are installed. You'll need to test the motors to see which way they turn.
Here's the instructions for setting the motor directions:
Before proceeding with the rest of the setup, save the changes to the header file and recompile and
load (to EEPROM) the modified code.
* Set Motor Directions *
With the modified code running in the robot, again turn
off the feedback portion of the program by typing "o"
in the terminal window.
The direction of the motors should now be checked.
The direction of the motors should match the direction
of the encoder feedback.
The characters ">" and "<" will be used to bracket
data to be entered into the terminal window. The
character "" will be used to indicate the "Enter"
key. To test the direction of motor #0 type the
following into the terminal window. >0700<. This
should turn on motor #0 (the front left motor) to
70% power. If the encoder direction did not need to
be reversed , the motor should be spinning in a direction
that would move the robot forward. The main thing to
check in with these motor tests is to see if he motor's
"targetSpeed" matches the direction of the motor's
"currentSpeed" positive "targetSpeed" should produce
positive "currentSpeed". If the two directions do not
match, then the constants "WHEEL_RED_0" and "WHEEL_BLACK_0"
will need to be switched.
Turn motor #0 off by typing >0<.
Test the direction of motor #1 (front right) by typing
>1700<. Again, check to see if the directions of
"targetSpeed" and "currentSpeed" match.
Turn motor #1 off by typing >1<.
Repeat this process for motor #2 (left rear) and motor
#3 (right rear).
Once the appropriate "WHEEL_RED_x" and "WHEEL_BLACK_x"
constants have been switched, recompile and load the
program.
That's all I have time for right now. Let me know if you need any of the above clarified or if you have any other questions. (I don't have Skype installed on this PC. If need be I could install it. I'd rather help on the forum so others wanting to also use this code can benefit from our exchange.)
I'm not sure if I've mentioned that this is the program I used to drive figure eights. If the robot doesn't receive any input to tell it to do otherwise, it will start trying to drive in a figure eight.
I think this should be easy to change. There's a line (#584) in the "Setup" method that sets the driveMode variable. The "SetUp" method is the first method in the top object "Demo4WDBot130226e.spin".
This should keep the motors off when the robot starts.
I haven't tested this yet (I don't want make any noise right now). I should be able to test this tomorrow to make sure the robot starts with its motors off.
I wasn't thinking about using the code on a slave Propeller when I posted the code. I just posted the version I had been using (to drive figure eights).
Hey duane thanks for all the info I have been following the steps to get it working. I am having trouble with the red and black wheel wires since I am using a different motor controller board
It has Cur(used to measure the current the wheel is pulling), direction, pwm, gnd pins for each motor. So I am not sure what pins would go where for the red and black.
Ok I see IN1 and IN 2 as motor 1 and IN 3 and IN 4 for motor 2 but I can't figure out how that corresponds to my board with direction pin and pwm pin instead of IN 1 and IN 2?
THe more research I do it seems that I cannot use the current motor controller with your code. Since my board does all the logic of the H bridge inside it you just pass it the dir and speed while yours you have to enA IN1 and IN2 to set high and low in order to give it a dir and speed. Let me know I might have to swap out the motor controllers to the L298.
here is the datasheet for my motor controller and it seems in one of the last paragraphs states the built in control logic allows the motors to be controlled by 2 pins dir and pwm.
Hey duane thanks for all the info I have been following the steps to get it working. I am having trouble with the red and black wheel wires since I am using a different motor controller board
It has Cur(used to measure the current the wheel is pulling), direction, pwm, gnd pins for each motor. So I am not sure what pins would go where for the red and black.
Thanks.
You motor controller uses PWM and direction which is different than what my driver's two "IN" connections and an enable connection. I've been meaning to add inverters to my motor controller so it would behave the same as yours.
For now, I think your controller could work by setting the "WHEEL_ENABLE_x" pin to the PWM pin and the "WHEEL_RED_x" to the direction pin. Set all the "WHEEL_BLACK_x" constants to some unused I/O pin (which will stay unconnected). I think all the "WHEEL_BLACK_x" constants could be set to the same pin number. If the motor direction doesn't match the encoder direction, you can switch the "WHEEL_RED_x" and "WHEEL_BLACK_x" constants.
I don't have any support for current sensing yet. I've been intending to add support for an ADC chip to my projects for measuring current. One of my boards has an MCP3208 chip installed but I haven't added the software to read it yet.
You could connect the "cur" pins to you other microcontroller's analog pins to monitor the current.
I just thought of something. The Rover 5 control board you're using has connections for the quadrature encoders which are then converted to single channel encoders. Don't use you motor control board encoder connections. The Propeller is expecting quadrature encoders not a single channel encoder. (Make sure and read the notes about using resistors on the encoder lines.)
Normally quadrature encoders would be able to tell you how far the robot had traveled. I think with Mecanum wheels, trying to make sense of the encoder information is much more difficult than with normal wheels,
All these different PCBs need to have a common ground connection.
My motor controller board has outputs for ENC1 and ENC2 and then a Single INT output. So I should be able to just pass the ENC1 and ENC2 pins to the parallax board correct and just not use the single INT pin which combines the two ENC 1 and ENC 2 into a single encoder?
Also should the encoder readings on the terminal be counting up and down or should they reset when the wheel stops spinning? It seems to go like move wheel forward 1 2 3 ...600 or reverse 600 599 598 .... 3 2 1 0 -1 -2 -3 etc ?
My motor controller board has outputs for ENC1 and ENC2 and then a Single INT output. So I should be able to just pass the ENC1 and ENC2 pins to the parallax board correct and just not use the single INT pin which combines the two ENC 1 and ENC 2 into a single encoder?
Correct. You don't want to connect the INT pins to the Propeller board. The yellow and white wires from the Rover 5 should connect through resistors to the Propeller. The red wire (grouped with the yellow and white wires) should be connected to 5V and the black wire (again, the black wire on the encoder bundle not the motor power wire) to ground.
Also should the encoder readings on the terminal be counting up and down or should they reset when the wheel stops spinning? It seems to go like move wheel forward 1 2 3 ...600 or reverse 600 599 598 .... 3 2 1 0 -1 -2 -3 etc ?
The encoders so not reset to zero unless you turn the wheel backwards as much as you turned it forward (this is a feature of quadrature encoders). I've seen encoder objects that allow the encoder to be reset to zero but I didn't have this need myself. You could record the previous encoder value to compare with new encoder values if you wanted to keep track of how far you've moved from some arbitrary point in time.
Hey wanted to check something about wiring up the parallax board. on the board it starts at 1 to 40 but in the datasheet it shows 1 as pin 0? so when coding up do I use 0 or 1 when referring to the pin labeled pin 1 on the board?
also forgot to ask why the 10k resistors on all the input pins to the board?
Hey wanted to check something about wiring up the parallax board. on the board it starts at 1 to 40 but in the datasheet it shows 1 as pin 0? so when coding up do I use 0 or 1 when referring to the pin labeled pin 1 on the board?
The Propeller has 32 general purpose I/O pins (four of these are used during boot up and it's generally not a good idea to use P28 - P31 for other devices unless you know what you're doing). The QuickStart has a 40 pin header. Header pins and physical pins on chips start their numbering with #1. The I/O pins are numbered starting with zero.
In the diagram below, P0 is located on the physical location #1 on the header. P1 is on location #2.
I use a label to help figure out which pin is which.
If you happen to have a Brother label maker, you can use the file in post #7 of this thread (about the QuickStart board), to print your own labels. If you don't have a label printer send me a PM with your address and I'll mail a few of these labels. (The label offer is good for anyone else reading this post.)
also forgot to ask why the 10k resistors on all the input pins to the board?
The Propeller is a 3.3V device and 5V will damage the chip if the current is above certain amount (500uA IIRC). As long as the resistor value is 3K or more, it should be okay. I use 10K since I have a lot of 10K resistors.
When I use the serial terminal it seems to output a lot of extra information, not as concise as what you had posted earlier.
I just posted the top section of the debug information earlier since it contains all the information you need to setup your robot. I have the program displaying a lot of data as I try to figure out what the program is doing.
You'll probably want to reduce the amount of information transmitted from the Propeller when you have it hooked up to your other uC.
The method "DebugCog" contains the main debug loop. If you comment out some of the method calls, less information will be displayed to the terminal window (or sent to the other uC). I think you'd be save to comment out the following methods:
PUB DebugCog
Pst.Start(115200)
repeat
'CheckOtherInputs
result := Pst.RxCount
if result
if state == WAITING_FOR_MOTOR_ID
DisplayMenuSpeed
elseif state == FIRST_DIGIT_SPEED or state == WAITING_FOR_SPEED
ReceiveSpeedInput
CheckNewData
DisplayTargetSpeed
DisplayEncoder
'DisplayPinStates
'if TEST_DIRECTIONS_FLAG == Bot#TEST_DIRECTIONS_OPERATION
DisplayPresentSpeed
'DisplaysSpeedBuffer
'DisplayControlData
You'll probably want to reduce the amount of information the Propeller sends to make it easier for your other uC to read the pertinent information. You can go through the remaining methods called by "DebugCog" and remove or change the information it transmits. Let me know if you need help editing the debug information.
When you connect the Propeller with your other uC you'll want the use the TX and RX lines. Since your other uC is a 5V device you'll want to use a resistor on the Prop's RX line.
I got the encoders to respond great and get current speed. But now I am trying to control the motors my motor controller and not sure if I am either not doing it right or is it jjust not compatible. I have it hooked up like this
Wheel enable 1 = pin 10 = pwm on my motor controller
wheel red 1 = pin 11 = direction on my motor controller
then I have the ground from my motor controller going to ground and the boards ground going to same ground. but no luck thus far.
Got it to spin a little bit but then it slowed down and stopped. Not sure if its the motor controller or the code since its not made for my board really.
Got it to spin a little bit but then it slowed down and stopped.
Had you typed anything into the keyboard? The default action is for the motor is to spin a bit and then stop.
I just tested the change I suggested in post #99 and it didn't work. I'll figure out to how to make sure the motors start out off and only turn on with keyboard input.
As it is now if you type the letter "o" it should turn off all the motors. You should be able to then type in motor and speed after that.
After starting the robot, type "o". Then type "0500" followed by enter (and without quotes). The front left wheel should spin at half speed. Type "0" enter to turn motor #0 off. (Assuming you have the pins for motor #0 set and wired correctly.)
If you're unsure your motor controller responds to 3.3V logic, you could try one of the motor control objects that use a direction pin to test it.
Okay, I tested a way to keep the motors off at start up.
In the "Setup" method of the top object change line #595 from:
keyboardFlag := 0
To: (You guessed it.)
keyboardFlag := 1
There's a bug in the posted version of the code that doesn't accept the first motor speed command entered. So the first command to change speed is ignored but subsequent commands should work.
I'm pretty sure I have this bug fixed in the version I'm presently working on but I've also added new bugs as I've been incorporating a compass.
I was inputting into the terminal 0700 for motor 1 to go speed 700 I saw in the code it was -1000 to 1000. But now that you say it doesnt take in the first command that you write to it I cant remember if I typed it in twice....I will have to try tomorrow inputting 0700 twice and see if it responds. I hope so!!!!
A> sometimes terminal will stay blank even after loading a program into the board I have to close out of propeller and reopen for it to show the information I have tried a bunch of alittle things enable disable etc but nothing working not sure if ehre is acommand to refresh maybe.
B> does the board run always whatever is in RAM ? if there is something in eeprom when it boots up and nothing in ram it will load into ram and run correct?
Tried to add another motor to the mix and the first motor started freaking out and grinding a lot had to cut it off . I am just going to grab some L298 H bridges and try to get it working instead of trying to force this board to fit, It has its own control logic so who knows what signals it is interpreting.
Ill post on Tue hopefully the boards will come in by then.
A> sometimes terminal will stay blank even after loading a program into the board I have to close out of propeller and reopen for it to show the information I have tried a bunch of alittle things enable disable etc but nothing working not sure if ehre is acommand to refresh maybe.
I don't know how to get around this problem. This used to happen to me relatively often. I don't have this problem much anymore, I don't know what I did, if anything, that made it better. I think it's a problem on the PC side of things.
Often if I close the terminal window and then reopen it, it behaves better.
B> does the board run always whatever is in RAM ? if there is something in eeprom when it boots up and nothing in ram it will load into ram and run correct?
The Propeller always runs from RAM. It loads the program from EEPROM to RAM at start up. It's possible to load a program from the PC directly to RAM but the program will be lost when the Prop reboots if the program hasn't been loaded to EEPROM.
Tried to add another motor to the mix and the first motor started freaking out and grinding a lot had to cut it off . I am just going to grab some L298 H bridges and try to get it working instead of trying to force this board to fit, It has its own control logic so who knows what signals it is interpreting.
Ill post on Tue hopefully the boards will come in by then.
Thanks
I looked through the comments I made in the program to see if I wrote down how to set the PWM frequency. I couldn't find any instructions so I'll give some here.
The frequency is set by setting the constant "MAXSPEED" in the object "FourMotors130223a.spin". The frequency can be computed with this equation:
PWM frequency = 80,000,000 / MAXSPEED
Presently I'm using the value 1,600,000 for MAXSPEED which make the frequency 50Hz. I decided 50Hz wasn't very bothersome. I had previously used 20KHz as my PWM frequency but it greatly reduced the power to the motors. I don't know if your motor control would have a problem with the 50Hz frequency or not. I doubt it would be a problem but I'm not sure.
Have you used the motors and motor control board with a different uC? Where you able to power all the motors at the same time? I looked back through the thread and see you're using two 7.2V NiCd packs. Do you know how much current these packs can supply? 7.2V might be a problem for the L298N motor controllers since they drop the voltage a bit (I think by 2V). Could your problems with the motors be related to the batteries?
I used it to control a figure 8. (Same video as in the figure 8 thread.)
The robot takes a heading reading before it starts the first loop. It then ignores the compass for two seconds to make sure it doesn't accidentally zigzag at the beginning of the loop. After the first two seconds of the loop it checks to see if it has passed the start heading.
Here's the portion of code that checks to see if the starting heading has been passed.
elseif driveMode == FIGURE_8_MODE ' ** Seems awkward to check modes in this method ' and AutoDrive method.
previousHeading := pseudoHeading
Control.RefreshInput
if watchCompassFlag == CCW_WATCH_COMPASS
if previousHeading > initialPseudoHeading and pseudoHeading =< initialPseudoHeading
watchCompassFlag := NO_WATCH_COMPASS
result := true
elseif watchCompassFlag == CW_WATCH_COMPASS
if previousHeading < initialPseudoHeading and pseudoHeading => initialPseudoHeading
watchCompassFlag := NO_WATCH_COMPASS
result := true
Since the compass transitions from -179 to +180 as it passes south, the above algorithm could have a problem if the robot started with a southern heading. I intend to take care of such possibilities in the future, but for now, I just make sure the robot is headed north at the beginning (most of my previous figure eights started out heading south).
I also want to make it so the robot can use the compass to figure out and adjust its turn rate.
It's kind of fun to start giving this robot some intelligence.
Hey duane, I have a 9v battery I can always try out if the voltage drop across the bridge is to much. I think the motors say 5v to 7.2v operating range so I might be able to get away with 7.2v batteries. I think the batteries are 1000mAh iirc. I have also tested all the motors with just the motor controller and they work fine that was using the arduino to control. Is there any way to figure out a good pwm frequency to set it to?, why 50hz might I ask.
Wanted to add that we were discussing using a compass instead of the 2 ultrasonics to make sure we drive straight and sideways . We are having issues with the ultrasonics and objects sometimes so we cannot rely on them always to make sure were driving straight. The tilt compensated ones are quite costly so we might just go without the tilt compensation . Still trying to figure out how we can adjust the speeds of wheels when its off.
In one of the above posts our theory was
when driving straight if it veers left then we need to slow down the right side and opposite if its veers right a simplistic approach so not sure if it will work in practice.
You can use an accelerometer to help with compass tilt, im not sure if it is any cheaper but it adds more functionality to your bot than a new compass. Also if you are after straight lines, check in to adding quadrature encoders to your bot. If you DIY them this will be super cheap and also allow you to do accurate speed control a long with dead reckoning and all kinds of cool odometery. I personally think encoders are one of the most important things you can add to a bot!
Ya actually thats what were working on in this thread is I am trying to integrate duanes pid controller into my robot. The rover 5 chassis has 4 quadrature encoders. The problem with an accelorometer is great for tilt but if were standing still we want to know which way we are oriented.
So I got the new H bridges in, I will be testing tomorrow. I had a quick question about the settings that you have for indepedent wheels or meccannum wheels what is the difference when setting these? Particularly when I go to send directions to the parallax board will I still send the motors signals like 0700 1700 2700 3700 or does the meccannum setting accept something different?obot to go sideways well we know how to program it to go sideways with arduino but if I am sending commands say 0700 0-500 0-500 0700 What does it pick to make the master speed to match all the motors to? another example just going straight 0700 1500 2700 3300 what would it choose to be the master speed to try to match all the motors together? Thanks.
Also was wondering about the slave part when I am sending serial out of my arduino do I need to have it in string or does it need to be an int that I send to the parallax board? for isntance "0700" when I type it into the serial terminal and the board reads it is it reading it as a string or integer?
Tried this on my arduino to just send a speed but not working It just sends 0700 with carriage return at the end through serial. I have my arduino TX hooked up to parallax RX , not sure if the usb being hooked on the parallax is interfering with the communication?
Comments
You can read Duane's love/hate relationship with the Rover 5 chassis in several of his threads. Looks neat, but pretty flexible, which may cause problems once the weight of the vehicle creeps up. Especially since mecanum wheels push & pull your wheels in all directions. Looks like your bot is getting heavy, so you might consider a different chassis. Even a hunk of plywood! http://www.youtube.com/watch?v=rAgiYtwuWB4
BTW, I'm a staunch advocate of slow, torquey DC motors with lots of gear reduction, because they will be pretty closely matched, RPM-wise. I've had good results with my simple mecanum bot, which doesn't even have encoders yet: http://www.youtube.com/watch?v=RPIfIOat6Os
I know I was thinking to myself as I clicked the link "I'd use a QuickStart of a Propeller Project Board if I were amano001." When the board wasn't a QuickStart my brain hallucinated a Project Board (it's the same size as a Proto Board). (Don't tell anyone about my hallucination, it's kind of embarrassing. Especially not erco!)
The reason I'd suggest the Project Board over the Proto Board is the Proto Board requires a Prop Plug to program it. There are lots of Propeller board that require a Prop Plug for programming but if you're only purchasing one board then a board with built in USB makes more sense. Both the QuickStart and the Propeller Project Board have on board USB and can be powered by the USB connection.
Here's a regulator I use when I need 5V on a robot.
I agree with erco about your robot starting to look a bit on the heavy side. One thing that might help is the use of a higher voltage battery pack. I originally used a 2 cell LiPo to power my robot but I had so many more 3 cell LiPos (used with my quadcopters) that I started using a 3 cell with this robot. The 12 Volts (probably dropped to 10V after the motor controller) is higher than the motors 7.2 volt rating but it's nice to have the extra power. I figure I'm shortening the life of the motors but I don't run the robot for very long when I use it so I thought risk wasn't too bad.
The previous robot we had built was using servos but now we switched over to the rover 5 chassis w/ motors because the shafts were starting to bend and cause slow down. The robot is a little heavy with the arm we wired up 2 in parallel 7.2v Nicad batteries for power and then we break down that power with 2 different 5v regulators for different parts. Running it off the board itself was just making it easier and less wires going everywhere but if we have to we will just add another temrinal block to run the servos and sensors off of.
Thanks for the info on the 3.3 logic we just wanted to make sure before we blew something up lol.
I am looking over your code now that you have uploaded, We are very short on time so it will be a lifesaver to not have to learn the propeller stuff right away and just use it as an integrated part of our robot.
Thanks and I will keep you updated on how things are going, the computer vision is a pain in itself.
Also wanted to ask you our logic behind making sure the robot is parallel with wall is using 2 ultraonics one on each corner and determining the distance they are off by parallel being u1-u2 = 0 if they are the same distance from the wall therefore they are parallel. If u1-u2 <0 means left side of robot is going faster then right side and opposite case for u1-u2 >0 . Do you think this is overthinking the process? We need to be very precise when the robot moves into positions on a board.
U1| Let Side Robot <======
|
|
|
U2|
Let me know if your available for a skype pow wow, my skype is mayong972
I have a bunch of instructions in the top object "Demo4WDBot13026e.spin".
Here's the section about setting encoder and motor pins:
The pin settings are in the file "HeaderMecanumQs_130226a.spin".
Here's the section:
The constant "WHEEL_RED_0" should be set to one of the two pins that control the front left motor. On my motor control PCB it's marked "IN1". "WHEEL_BLACK_0" connects to the other motor controller pin ("IN2" on my board).
Don't worry about which way the motors spin to start with. You'll want to get the encoder directions figured out first and then come back and set the motor pins so they agree with the encoders.
I've made it so you don't have to switch encoder wires or motor wires if you don't want to. The directions of both the encoders and motors can be set with the constants in the header file. Depending on your setup, it might be easier just to switch wires rather than changing constant values.
During this initial setup phase, you'll want to make sure the line"INPUT_TYPE = PC_ONLY_INPUT" is not commented out. Here's the section of code to look for.
' inputType enumeration #0, PC_ONLY_INPUT, WII_NUNCHUCK_INPUT, RC_INPUT, WII_AND_RC_INPUT, AUTO_DETECT_INPUT INPUT_TYPE = PC_ONLY_INPUT '' Use this when first setting up robot 'INPUT_TYPE = WII_NUNCHUCK_INPUT 'INPUT_TYPE = RC_INPUT 'INPUT_TYPE = WII_AND_RC_INPUT '' Not yet supported. If used it will behave the same '' as AUTO_DETECT_INPUT. 'INPUT_TYPE = AUTO_DETECT_INPUT '' Priority given to NunchuckYou shouldn't need to change this since the appropriate line is already active.
I did notice a section of code in the header with an incorrect setting.
I'm not sure why I had the active mode set as "WHEEL_MODE = TREADED_WHEELS".
While you're setting up your robot, you should change the above code to:
This will let you control the speed of each motor independently from the rest of the motors. You'll probably want to keep it set to "INDEPENDENT_WHEELS" when you're sending it instructions from your other microcontroller.
While you're in the header file, you'll want to set "PROPORTIONAL_CONSTANT" to zero while you're setting up the motor and encoders. This will keep the motors from spinning at full speed if the encoders' directions don't match the motors' directions.
You'll want to make sure and use resistors between the Rover 5's encoders and Propeller's I/O pins.
Once you have the above constants all set, you'll want to load the top object "Demo4WDBot130226e" into your Propeller board's EEPROM (by pressing "F11").
Open the Parallax Serial Terminal (by pressing F12). With the baud set to 115,200 and with the appropriate comm port selected, you should see a bunch of data in the terminal window.
Something like this:
Target Speeds: targetSpeed[0] = 0, child[0] = 0 targetSpeed[1] = 0, child[1] = 0 targetSpeed[2] = 0, child[2] = 0 targetSpeed[3] = 0, child[3] = 0 Current Speeds: currentSpeed[0] = 0, output[0] = 0 currentSpeed[1] = 0, output[1] = 0 currentSpeed[2] = 0, output[2] = 0 currentSpeed[3] = 0, output[3] = 0 Current Encoder Readings: encoder[0] = 0 encoder[1] = 0 encoder[2] = 0 encoder[3] = 0 3 2 1 1098_7654_3210_9876_5432_1098_7654_3210 Ina = %1111_0000_0000_0000_0010_0000_0000_0000You'll want to pay attention to the "currentSpeed" values. Turning the wheels in the direction that would cause the robot to move forward should produce positive speed. If the speed is negative, then you'll want to do one of two things.
If you're encoder pins are easy to switch, just switch the two encoder pins for that particular wheel. The other way to deal with a negative speed with positive wheel motion is to change the constants "FORWARD0" through "FORWARD3". Change the constant that corresponds to wheel from "1" to "-1".
Once all the "currentSpeed" values give positive speed with forward robot motion, you'll want to make sure the motors' directions match the encoder directions. There's no guarantee which way the motors will turn when power is applied to the red and black wires. Some of these wires are reversed when they are installed. You'll need to test the motors to see which way they turn.
Here's the instructions for setting the motor directions:
That's all I have time for right now. Let me know if you need any of the above clarified or if you have any other questions. (I don't have Skype installed on this PC. If need be I could install it. I'd rather help on the forum so others wanting to also use this code can benefit from our exchange.)
I think this should be easy to change. There's a line (#584) in the "Setup" method that sets the driveMode variable. The "SetUp" method is the first method in the top object "Demo4WDBot130226e.spin".
Here's the section of code:
Change:
To:
This should keep the motors off when the robot starts.
I haven't tested this yet (I don't want make any noise right now). I should be able to test this tomorrow to make sure the robot starts with its motors off.
I wasn't thinking about using the code on a slave Propeller when I posted the code. I just posted the version I had been using (to drive figure eights).
https://www.sparkfun.com/products/11593
It has Cur(used to measure the current the wheel is pulling), direction, pwm, gnd pins for each motor. So I am not sure what pins would go where for the red and black.
Ok I see IN1 and IN 2 as motor 1 and IN 3 and IN 4 for motor 2 but I can't figure out how that corresponds to my board with direction pin and pwm pin instead of IN 1 and IN 2?
THe more research I do it seems that I cannot use the current motor controller with your code. Since my board does all the logic of the H bridge inside it you just pass it the dir and speed while yours you have to enA IN1 and IN2 to set high and low in order to give it a dir and speed. Let me know I might have to swap out the motor controllers to the L298.
http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Robotics/4 Channel instruction manual.pdf
here is the datasheet for my motor controller and it seems in one of the last paragraphs states the built in control logic allows the motors to be controlled by 2 pins dir and pwm.
Thanks.
You motor controller uses PWM and direction which is different than what my driver's two "IN" connections and an enable connection. I've been meaning to add inverters to my motor controller so it would behave the same as yours.
For now, I think your controller could work by setting the "WHEEL_ENABLE_x" pin to the PWM pin and the "WHEEL_RED_x" to the direction pin. Set all the "WHEEL_BLACK_x" constants to some unused I/O pin (which will stay unconnected). I think all the "WHEEL_BLACK_x" constants could be set to the same pin number. If the motor direction doesn't match the encoder direction, you can switch the "WHEEL_RED_x" and "WHEEL_BLACK_x" constants.
I don't have any support for current sensing yet. I've been intending to add support for an ADC chip to my projects for measuring current. One of my boards has an MCP3208 chip installed but I haven't added the software to read it yet.
You could connect the "cur" pins to you other microcontroller's analog pins to monitor the current.
I just thought of something. The Rover 5 control board you're using has connections for the quadrature encoders which are then converted to single channel encoders. Don't use you motor control board encoder connections. The Propeller is expecting quadrature encoders not a single channel encoder. (Make sure and read the notes about using resistors on the encoder lines.)
Normally quadrature encoders would be able to tell you how far the robot had traveled. I think with Mecanum wheels, trying to make sense of the encoder information is much more difficult than with normal wheels,
All these different PCBs need to have a common ground connection.
Correct. You don't want to connect the INT pins to the Propeller board. The yellow and white wires from the Rover 5 should connect through resistors to the Propeller. The red wire (grouped with the yellow and white wires) should be connected to 5V and the black wire (again, the black wire on the encoder bundle not the motor power wire) to ground.
The encoders so not reset to zero unless you turn the wheel backwards as much as you turned it forward (this is a feature of quadrature encoders). I've seen encoder objects that allow the encoder to be reset to zero but I didn't have this need myself. You could record the previous encoder value to compare with new encoder values if you wanted to keep track of how far you've moved from some arbitrary point in time.
also forgot to ask why the 10k resistors on all the input pins to the board?
The Propeller has 32 general purpose I/O pins (four of these are used during boot up and it's generally not a good idea to use P28 - P31 for other devices unless you know what you're doing). The QuickStart has a 40 pin header. Header pins and physical pins on chips start their numbering with #1. The I/O pins are numbered starting with zero.
In the diagram below, P0 is located on the physical location #1 on the header. P1 is on location #2.
I use a label to help figure out which pin is which.
If you happen to have a Brother label maker, you can use the file in post #7 of this thread (about the QuickStart board), to print your own labels. If you don't have a label printer send me a PM with your address and I'll mail a few of these labels. (The label offer is good for anyone else reading this post.)
The Propeller is a 3.3V device and 5V will damage the chip if the current is above certain amount (500uA IIRC). As long as the resistor value is 3K or more, it should be okay. I use 10K since I have a lot of 10K resistors.
I just posted the top section of the debug information earlier since it contains all the information you need to setup your robot. I have the program displaying a lot of data as I try to figure out what the program is doing.
You'll probably want to reduce the amount of information transmitted from the Propeller when you have it hooked up to your other uC.
The method "DebugCog" contains the main debug loop. If you comment out some of the method calls, less information will be displayed to the terminal window (or sent to the other uC). I think you'd be save to comment out the following methods:
PUB DebugCog Pst.Start(115200) repeat 'CheckOtherInputs result := Pst.RxCount if result if state == WAITING_FOR_MOTOR_ID DisplayMenuSpeed elseif state == FIRST_DIGIT_SPEED or state == WAITING_FOR_SPEED ReceiveSpeedInput CheckNewData DisplayTargetSpeed DisplayEncoder 'DisplayPinStates 'if TEST_DIRECTIONS_FLAG == Bot#TEST_DIRECTIONS_OPERATION DisplayPresentSpeed 'DisplaysSpeedBuffer 'DisplayControlDataYou'll probably want to reduce the amount of information the Propeller sends to make it easier for your other uC to read the pertinent information. You can go through the remaining methods called by "DebugCog" and remove or change the information it transmits. Let me know if you need help editing the debug information.
When you connect the Propeller with your other uC you'll want the use the TX and RX lines. Since your other uC is a 5V device you'll want to use a resistor on the Prop's RX line.
I got the encoders to respond great and get current speed. But now I am trying to control the motors my motor controller and not sure if I am either not doing it right or is it jjust not compatible. I have it hooked up like this
Wheel enable 1 = pin 10 = pwm on my motor controller
wheel red 1 = pin 11 = direction on my motor controller
then I have the ground from my motor controller going to ground and the boards ground going to same ground. but no luck thus far.
Had you typed anything into the keyboard? The default action is for the motor is to spin a bit and then stop.
I just tested the change I suggested in post #99 and it didn't work. I'll figure out to how to make sure the motors start out off and only turn on with keyboard input.
As it is now if you type the letter "o" it should turn off all the motors. You should be able to then type in motor and speed after that.
After starting the robot, type "o". Then type "0500" followed by enter (and without quotes). The front left wheel should spin at half speed. Type "0" enter to turn motor #0 off. (Assuming you have the pins for motor #0 set and wired correctly.)
If you're unsure your motor controller responds to 3.3V logic, you could try one of the motor control objects that use a direction pin to test it.
In the "Setup" method of the top object change line #595 from:
To: (You guessed it.)
There's a bug in the posted version of the code that doesn't accept the first motor speed command entered. So the first command to change speed is ignored but subsequent commands should work.
I'm pretty sure I have this bug fixed in the version I'm presently working on but I've also added new bugs as I've been incorporating a compass.
thanks for responding.
A> sometimes terminal will stay blank even after loading a program into the board I have to close out of propeller and reopen for it to show the information I have tried a bunch of alittle things enable disable etc but nothing working not sure if ehre is acommand to refresh maybe.
B> does the board run always whatever is in RAM ? if there is something in eeprom when it boots up and nothing in ram it will load into ram and run correct?
Ill post on Tue hopefully the boards will come in by then.
Thanks
I don't know how to get around this problem. This used to happen to me relatively often. I don't have this problem much anymore, I don't know what I did, if anything, that made it better. I think it's a problem on the PC side of things.
Often if I close the terminal window and then reopen it, it behaves better.
The Propeller always runs from RAM. It loads the program from EEPROM to RAM at start up. It's possible to load a program from the PC directly to RAM but the program will be lost when the Prop reboots if the program hasn't been loaded to EEPROM.
I looked through the comments I made in the program to see if I wrote down how to set the PWM frequency. I couldn't find any instructions so I'll give some here.
The frequency is set by setting the constant "MAXSPEED" in the object "FourMotors130223a.spin". The frequency can be computed with this equation:
PWM frequency = 80,000,000 / MAXSPEED
Presently I'm using the value 1,600,000 for MAXSPEED which make the frequency 50Hz. I decided 50Hz wasn't very bothersome. I had previously used 20KHz as my PWM frequency but it greatly reduced the power to the motors. I don't know if your motor control would have a problem with the 50Hz frequency or not. I doubt it would be a problem but I'm not sure.
Have you used the motors and motor control board with a different uC? Where you able to power all the motors at the same time? I looked back through the thread and see you're using two 7.2V NiCd packs. Do you know how much current these packs can supply? 7.2V might be a problem for the L298N motor controllers since they drop the voltage a bit (I think by 2V). Could your problems with the motors be related to the batteries?
I used it to control a figure 8. (Same video as in the figure 8 thread.)
The robot takes a heading reading before it starts the first loop. It then ignores the compass for two seconds to make sure it doesn't accidentally zigzag at the beginning of the loop. After the first two seconds of the loop it checks to see if it has passed the start heading.
Here's the portion of code that checks to see if the starting heading has been passed.
elseif driveMode == FIGURE_8_MODE ' ** Seems awkward to check modes in this method ' and AutoDrive method. previousHeading := pseudoHeading Control.RefreshInput if watchCompassFlag == CCW_WATCH_COMPASS if previousHeading > initialPseudoHeading and pseudoHeading =< initialPseudoHeading watchCompassFlag := NO_WATCH_COMPASS result := true elseif watchCompassFlag == CW_WATCH_COMPASS if previousHeading < initialPseudoHeading and pseudoHeading => initialPseudoHeading watchCompassFlag := NO_WATCH_COMPASS result := trueSince the compass transitions from -179 to +180 as it passes south, the above algorithm could have a problem if the robot started with a southern heading. I intend to take care of such possibilities in the future, but for now, I just make sure the robot is headed north at the beginning (most of my previous figure eights started out heading south).
I also want to make it so the robot can use the compass to figure out and adjust its turn rate.
It's kind of fun to start giving this robot some intelligence.
Wanted to add that we were discussing using a compass instead of the 2 ultrasonics to make sure we drive straight and sideways . We are having issues with the ultrasonics and objects sometimes so we cannot rely on them always to make sure were driving straight. The tilt compensated ones are quite costly so we might just go without the tilt compensation . Still trying to figure out how we can adjust the speeds of wheels when its off.
In one of the above posts our theory was
when driving straight if it veers left then we need to slow down the right side and opposite if its veers right a simplistic approach so not sure if it will work in practice.
You can use an accelerometer to help with compass tilt, im not sure if it is any cheaper but it adds more functionality to your bot than a new compass. Also if you are after straight lines, check in to adding quadrature encoders to your bot. If you DIY them this will be super cheap and also allow you to do accurate speed control a long with dead reckoning and all kinds of cool odometery. I personally think encoders are one of the most important things you can add to a bot!
So I got the new H bridges in, I will be testing tomorrow. I had a quick question about the settings that you have for indepedent wheels or meccannum wheels what is the difference when setting these? Particularly when I go to send directions to the parallax board will I still send the motors signals like 0700 1700 2700 3700 or does the meccannum setting accept something different?obot to go sideways well we know how to program it to go sideways with arduino but if I am sending commands say 0700 0-500 0-500 0700 What does it pick to make the master speed to match all the motors to? another example just going straight 0700 1500 2700 3300 what would it choose to be the master speed to try to match all the motors together? Thanks.
Tried this on my arduino to just send a speed but not working It just sends 0700 with carriage return at the end through serial. I have my arduino TX hooked up to parallax RX , not sure if the usb being hooked on the parallax is interfering with the communication?
char str[ ] = "0700\n";
void setup() {
Serial.begin(115200);
Serial.write(str);
}
void loop() {
}