So I have seen this thing do figure 8s mecanum style, I've seen it romp around the snow, it has been coming a long very nice! What is the deal with the machine vision at this point though?
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?
Right now, there isn't a difference when using the Propeller as a slave. When I'm using the program as a master program the Mecanum setting will watch for different joystick inputs than with the independent setting.
I plan to make the Mecanum features availble when using the Propeller as a slave device. I'd add the ability to send three parameters to set the wheel speeds for Mecanum movement. Speed, direction and rotation would be the three parameters. This shouldn't be too hard to add to the current code, I'm just really busy this week.
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.
The equations for computing the individual Mecanum wheel speeds is part of the program I posted. You could translate the equations into C for the Arduino. I also attached a pdf with these equations earlier in the thread.
If you enter four different speeds each motor will try to maintain its specific speed. It wont worry about the wheels fighting each other. If the wheels are fighting it will likely just cause some of the wheels to spin in place. The program doesn't choose one speed to be a "master speed". If you want the robot to move forward at about half speed you'd send "0500cr1500cr2500cr3500cr" the "cr" represents a carriage return.
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?
'
The board is reading it as a string. You'd send the same charaters as if you where having the Arduino communicate with a PC terminal window. The Arduino's serial library probaby has a way of sending variables as ASCII characters.
So I have seen this thing do figure 8s mecanum style, I've seen it romp around the snow, it has been coming a long very nice! What is the deal with the machine vision at this point though?
That's the "In Progress" part.
I did post about a few machine vision experiments early in this thread. I haven't posted about machine vision lately but I've been thinking about it a lot. I hope to have some progress to report soon. I have to get caught up with my day job first.
In regards to this post, I have a question the board is putting out a 3.3v signal to the ENA IN1 IN2 as shown in your schematic in the democode, H bridge so why would you need 10k resistor to protect the board from itself? I could understand the resistors from the encoder to the board because the encoders are spitting out a 5v signal.
Originally Posted by amano001
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.
In regards to this post, I have a question the board is putting out a 3.3v signal to the ENA IN1 IN2 as shown in your schematic in the democode, H bridge so why would you need 10k resistor to protect the board from itself? I could understand the resistors from the encoder to the board because the encoders are spitting out a 5v signal.
That's easy to answer. It's erco's fault.
Since erco mention destroying a Basic Stamp by using it with these motor control boards, I thought I'd play it save and use resisters on the lines between the Propeller and the motor control board.
You're correct to think the resistors shouldn't be needed. The motor controllers may work better without the resistors. I was just too chicken to try it with these cheap ebay boards.
Awesome to hear from you !, Just to clarify on the wheels matching up with their own speed. So I send 0500 1500 2500 3500 each wheel is trying to stay at the true 500 speed and not vary at all making them go all the same speed correct? Because usually when we were first trying to write a PID each wheel we would send say 500 to the motor and they would all go different speeds because they are not technically the exact same motor . So my understanding is that with your code the 500 speed is a master speed and each wheel is trying to match what 500 really is not what the motor thinks 500 is? Let me know if I need to clarify I might have wrote that a bit confusing.
Also wanted to ask so when I set up my wheels with encoders I will keep indepedent wheels as my selection and not the mecannum selection since I am not using a joystick correct?
That stamp gave its life because I was using the L298's 5V regulator to power the stamp. Would have worked if my motor battery voltage was 12V or less, but I was using 30V and fried the regulator, which took out the BS2 through overvoltage. Unrelated to the I/O lines.
But IIRC the L298 can be blown up via shoot-through if both control lines are made high simultaneously.
As my old HERO Jr robot is wont to say, "Smoking transistors is hazardous to my health..."
I'm on the road on a family vacation, currently broadcasting from near Columbia, SC (somewhere near doggiedoc... Spartanburg or Greenville IIRC?) and near Cincy OH next week (mindrobots, I won't quite get to Medina).
Hmm the serial communication seemed a lot easier then I thought still having issues trying to get the arduino to send out a string to the parallax board for control. I have tried most of the things I would think are wrong with it.
Any ideas duane? Serial.write sends the information as ASCII so I dont see why the parallax board isnt reading that as a command?
Hmm the serial communication seemed a lot easier then I thought still having issues trying to get the arduino to send out a string to the parallax board for control. I have tried most of the things I would think are wrong with it.
Any ideas duane? Serial.write sends the information as ASCII so I dont see why the parallax board isnt reading that as a command?
Serial.write("01000\n");
Does "01000" show on the Arduino terminal window if you send the data there? Are you writing "01000" twice? What's your current code look like?
When we do arduino to arduino communication through serial it works fine.
But we do something like this
Arduino 1
Serial.Write("hey");
Arduino2
If(serial.read()=="hey")
then turn on light
Im not sure if when were doing arduino to parallax if the parallax is always listening on the RX pin? or do we need to code in that like we did above.
and when you said
Does "01000" show on the Arduino terminal window if you send the data there? Are you writing "01000" twice? What's your current code look like?
What do you mean does it show on the arudino terminal? Do you mean from parallax to arduino? I am writing 01000 twice yes. Current code is still similar to the one I posted above
I have tried slight variations of this code but no luck yet. I am not sure if its the parallax board not listening or reading the incomming data. I am going to try tonight to just set up basic communication between my quickstart and arduino tot urn on an led.
When we do arduino to arduino communication through serial it works fine.
But we do something like this
Arduino 1
Serial.Write("hey");
Arduino2
If(serial.read()=="hey")
then turn on light
Im not sure if when were doing arduino to parallax if the parallax is always listening on the RX pin? or do we need to code in that like we did above.
and when you said
Does "01000" show on the Arduino terminal window if you send the data there? Are you writing "01000" twice? What's your current code look like?
What do you mean does it show on the arudino terminal? Do you mean from parallax to arduino? I am writing 01000 twice yes. Current code is still similar to the one I posted above
I have tried slight variations of this code but no luck yet. I am not sure if its the parallax board not listening or reading the incomming data. I am going to try tonight to just set up basic communication between my quickstart and arduino tot urn on an led.
I think I recall reading that the Arduino automatically adds a carriage return at the end of a line. This extra carriage return may be setting motor #0 to zero.
Here are few things to try.
Try the same code but for motor 1.
Try adding a pause between serial commands (half second).
Strange thing I got the arduino to print out on the parallax terminal but only by having the arduino TX pin hooked to the parallax TX pin. I think this is because the TX pin is hooked to the usb on the computer so its showing up on the parallax terminal.The picture shows the print outs of 1700 so its receiving the correct thing.I tried all the above no luck. Maybe I am missing a piece of receiving coding, like the parallax is missing the incomming information and I need to store it and then pass it to the motor function?
im thinking it may be a parsing issue on the parallax side? I cant seem to find in your code where you set whatever serial is to motor speed? Maybe I can insert a function similar to arduinos serial.read() to store what is typed from arduino and then pass it to the motor function as target speed?
GOT IT TO WORK!!!! I have no idea why but I was trying to shift down the 5v from the arduino TX to the RX parallax with a voltage divider to 3.3v but by connecting it directly from the arduino TX to the parallax RX it worked magically, I hope you have an explanation for me lol.
Ok next problem when were sending with terminal the wheels are getting the commands one after another
like
0700
1700
2700
3700
-the wheels start up about 1 second after each other
but there is a delay between when the parallax is receiving commands due to serial, Trying to think of ways to get around it. I know when your controlling it with your remote that they all move in unison I am assuming you have some functions that you use to send the motor commands all at once.
Ok next problem when were sending with terminal the wheels are getting the commands one after another
like
0700
1700
2700
3700
-the wheels start up about 1 second after each other
but there is a delay between when the parallax is receiving commands due to serial, Trying to think of ways to get around it. I know when your controlling it with your remote that they all move in unison I am assuming you have some functions that you use to send the motor commands all at once.
I wouldn't have thought the delay was that bad.
I don't remember if I had you change the value of the proportional constant to zero or not. If I did, you'll want to set it back to its original value (in the header file).
PROPORTIONAL_CONSTANT = 10
You could also speed up the input by removing a lot of the debug information. The serial input is received with the same cog as the cog displaying the debug information. My guess is all that debug information is slowing thinks down.
I have a version of the code I'm working on that will receive direction and speed information and the program will compute the individual wheel speeds automatically. I'm just haven't spent the time needed to get that version of the program working correctly.
We were maybe thinking of attaching 6 arduino pins to the parallax board and controlling the motors by using the pwm pins. Would this be a possibility? I am going to try commenting out some of the debug info and see if that speeds up.
Also not sure why the serial pin is only working with a direct connection from the arduino to the parallax. We think we might have blown the chip by running it direct 5v to 3.3v even though it was working. We tried using a voltage divider to lower it to 3.3v but it would not work. Maybe we should get a logic level shifter to 3.3v? The board is not sensing any chip now after we came back from eating dinner for some odd reason. It keeps saying no chip is found on com 8 we have tried different computers turning it on and off all kinds of things and still doesnt want to program now all the sudden. Maybe the direct connection from arduino to parallax blew it up.
Also not sure why the serial pin is only working with a direct connection from the arduino to the parallax. We think we might have blown the chip by running it direct 5v to 3.3v even though it was working. We tried using a voltage divider to lower it to 3.3v but it would not work. Maybe we should get a logic level shifter to 3.3v? The board is not sensing any chip now after we came back from eating dinner for some odd reason. It keeps saying no chip is found on com 8 we have tried different computers turning it on and off all kinds of things and still doesnt want to program now all the sudden. Maybe the direct connection from arduino to parallax blew it up.
You don't need a voltage divider, just a series resistor of at least 3K. I usually use 10K when reading a 5V signal with the Prop.
This is what I commented out almost everything in the debug cog I was actually thinking of just getting rid of this cog but not sure if there is anything in it that needs to be kept. But it runs a little bit smoother defintely a hell of a lot ebtter then it was. They seem to be almost in unison but sometimes it does mess up. Going to try messing with your RC input.
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
I was wondering if tehre was any stuff above that I could also get rid of?
Is there a possibility of using RCINPUT through the arduino pwm pins or is it a long shot? were just not sure exactly about how your code is running the RC we assume we need Throttle X Y pins from your code, maybe not even throttle depending on how X and Y function. Were not sure what all 6 channels do from the RC input either or what we would need to keep. We just need the robot to move forward back left and right possible turn in place. We are not sure about relying on the serial terminal input.
We cannot reliably get serial to work even with a lot of the debug code commented out . Sometimes it will work nicely othertimes some wheels wont turn on etc. Not sure where to go from here we feel stuck.
Is there any way we can just have it send end one motor command like 700 or -700 and then write our own little function like go straight or go backwards in parallax and integrate it into your code?
Is there any way we can just have it send end one motor command like 700 or -700 and then write our own little function like go straight or go backwards in parallax and integrate it into your code?
Of course. I posted the code. You can modify any way you like.
So would it be possible to just send PWM signals from the arduino to control the robot through RC receiver input? Which pieces would we need throttle, X and Y? Also if we wanted to restrict it dwn to 3 pins what else would we need to change besides the POSSIBLE CHANNELS variables down to 3?
Also would we need to change INDEPDENT WHEELS to MECANNUM WHEELS?
So would it be possible to just send PWM signals from the arduino to control the robot through RC receiver input? Which pieces would we need throttle, X and Y? Also if we wanted to restrict it dwn to 3 pins what else would we need to change besides the POSSIBLE CHANNELS variables down to 3?
Also would we need to change INDEPDENT WHEELS to MECANNUM WHEELS?
Yes, you could send pulses to the pins that would normally read the RC receiver. Here's the list of constants from the controller object.
Hmmm So we changed the RADIO Pin = 9 which would be 9 10 11 12 13 14 are the active pins 10 11 12 should be X Y Rotate how do we turn off all the other pins so it does not get hung up waiting for pwm pulses from throttle and gear aux?
Also is there anything else we would need to change ? can't seem to figure out why were not getting any movement.
Me and my friend have been working on another way to control the parallax through using serial still but also using functions that control the motors all at once.
repeat
if Pst.CharIn == "S"
Bot.Straight(500)
So I added this to main to wait for a command from the arduino and it works reliable so far. I am thinking of adding a case statement when I add in more commands such as move left move right rotate etc. The problem I am having is writing a new function to add to the obj Bot. I see Straight is written like this
PUB Straight(localSpeed)
globalSpeed := localSpeed
command := STRAIGHT_CMD
But i dont quite understand where the wheels are actually being set, so if I wanted to write a left and right function where would I need to access or send the speeds?
I think I may have figured it out this is where the actual settings is made. So from mainloop pub straight is called passed local speed then global speed is set and command is set to straight cmd then case statement chooses priv straight which then sets the motor speeds?
PRI StraightPrivate
repeat result from 0 to HIGHEST_MOTOR_ID
long[targetPtr][result] := globalSpeed
SetSpeedsPrivate
command := INDIVIDUAL_CMD
PRI RightPrivate
repeat result from 0 to HIGHEST_MOTOR_ID
//This part I am not sure how to set the individual motors I would need Front left and back left motors going away from each other 0700 1-700 and then front right and back right going towards each other 2-700 3700
The code has gone through several modifications so there is some redundancy. Both the "Bot" object and the "Control" object (as well as the top object can all change the speed of the wheels.
The various ways of changing the speed always ends up changing the global array in the top object "targetSpeed". The address of this array gets passed to the other objects so they can modify it directly.
I think your idea of adding additional "case" options is a good one. That's the way I'd do it.
The Mecanum equations are in the "Control" object. I see there's a public method for setting the direction and speed.
By passing the method your desired speed and direction of travel, it will compute the four wheel speeds for you (zero degrees is to the right and 90 degrees is straight ahead). Unfortunately I don't see a method for setting the rotation.
If you use the "Control" object in this way, you'll need to change the input type back to PC only.
What would be your desired interface? If you limit yourself to serial commands, what would you want the program to be able to do?
I'm working on this program right now to improve its low speed control and I could add a few features to make it easier to control through a serial connection. So what kind of commands would you want it to accept? Not that I'm making promises to include these features but I might and I might make changes you suggest if they seem like a good features to add.
I was thinking it would be good to be able to send a command to set the speed, direction and rotation. There's already a stop command.
Let me know what commands you'd like it to be able to accept.
Comments
Right now, there isn't a difference when using the Propeller as a slave. When I'm using the program as a master program the Mecanum setting will watch for different joystick inputs than with the independent setting.
I plan to make the Mecanum features availble when using the Propeller as a slave device. I'd add the ability to send three parameters to set the wheel speeds for Mecanum movement. Speed, direction and rotation would be the three parameters. This shouldn't be too hard to add to the current code, I'm just really busy this week.
The equations for computing the individual Mecanum wheel speeds is part of the program I posted. You could translate the equations into C for the Arduino. I also attached a pdf with these equations earlier in the thread.
If you enter four different speeds each motor will try to maintain its specific speed. It wont worry about the wheels fighting each other. If the wheels are fighting it will likely just cause some of the wheels to spin in place. The program doesn't choose one speed to be a "master speed". If you want the robot to move forward at about half speed you'd send "0500cr1500cr2500cr3500cr" the "cr" represents a carriage return.
'
The board is reading it as a string. You'd send the same charaters as if you where having the Arduino communicate with a PC terminal window. The Arduino's serial library probaby has a way of sending variables as ASCII characters.
Did you try sending it twice? Remember the bug in the code.
I wouldn't think the USB connection would cause a problem, but I'm not positive it wouldn't.
I don't use the Arduino much, but if you modified the program to send the command several times, I think it should work.
That's the "In Progress" part.
I did post about a few machine vision experiments early in this thread. I haven't posted about machine vision lately but I've been thinking about it a lot. I hope to have some progress to report soon. I have to get caught up with my day job first.
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.
Thanks duane i hope you get back soon! lol
That's easy to answer. It's erco's fault.
Since erco mention destroying a Basic Stamp by using it with these motor control boards, I thought I'd play it save and use resisters on the lines between the Propeller and the motor control board.
You're correct to think the resistors shouldn't be needed. The motor controllers may work better without the resistors. I was just too chicken to try it with these cheap ebay boards.
Thanks, but I haven't gone anywhere. I work from home but I have a lot of work to catch up on so I don't have much time from electronics right now.
Also wanted to ask so when I set up my wheels with encoders I will keep indepedent wheels as my selection and not the mecannum selection since I am not using a joystick correct?
But IIRC the L298 can be blown up via shoot-through if both control lines are made high simultaneously.
As my old HERO Jr robot is wont to say, "Smoking transistors is hazardous to my health..."
I'm on the road on a family vacation, currently broadcasting from near Columbia, SC (somewhere near doggiedoc... Spartanburg or Greenville IIRC?) and near Cincy OH next week (mindrobots, I won't quite get to Medina).
Any ideas duane? Serial.write sends the information as ASCII so I dont see why the parallax board isnt reading that as a command?
Serial.write("01000\n");
Does "01000" show on the Arduino terminal window if you send the data there? Are you writing "01000" twice? What's your current code look like?
But we do something like this
Arduino 1
Serial.Write("hey");
Arduino2
If(serial.read()=="hey")
then turn on light
Im not sure if when were doing arduino to parallax if the parallax is always listening on the RX pin? or do we need to code in that like we did above.
and when you said
Does "01000" show on the Arduino terminal window if you send the data there? Are you writing "01000" twice? What's your current code look like?
What do you mean does it show on the arudino terminal? Do you mean from parallax to arduino? I am writing 01000 twice yes. Current code is still similar to the one I posted above
char str[ ] = "0700\n";
void setup() {
Serial.begin(115200);
Serial.write(str);
Serial.write(str);
}
void loop() {
}
I have tried slight variations of this code but no luck yet. I am not sure if its the parallax board not listening or reading the incomming data. I am going to try tonight to just set up basic communication between my quickstart and arduino tot urn on an led.
I think I recall reading that the Arduino automatically adds a carriage return at the end of a line. This extra carriage return may be setting motor #0 to zero.
Here are few things to try.
Try the same code but for motor 1.
Try adding a pause between serial commands (half second).
Try the code without a "/n" added to the end.
Thanks
like
0700
1700
2700
3700
-the wheels start up about 1 second after each other
but there is a delay between when the parallax is receiving commands due to serial, Trying to think of ways to get around it. I know when your controlling it with your remote that they all move in unison I am assuming you have some functions that you use to send the motor commands all at once.
I wouldn't have thought the delay was that bad.
I don't remember if I had you change the value of the proportional constant to zero or not. If I did, you'll want to set it back to its original value (in the header file).
You could also speed up the input by removing a lot of the debug information. The serial input is received with the same cog as the cog displaying the debug information. My guess is all that debug information is slowing thinks down.
I have a version of the code I'm working on that will receive direction and speed information and the program will compute the individual wheel speeds automatically. I'm just haven't spent the time needed to get that version of the program working correctly.
You don't need a voltage divider, just a series resistor of at least 3K. I usually use 10K when reading a 5V signal with the Prop.
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
I was wondering if tehre was any stuff above that I could also get rid of?
'CheckNewData 'commented
'DisplayTargetSpeed ' commented
'DisplayEncoder ' commented
'DisplayPinStates ' commented
' if TEST_DIRECTIONS_FLAG == Bot#TEST_DIRECTIONS_OPERATION
'DisplayPresentSpeed ' commented
'DisplaysSpeedBuffer ' commented
'DisplayControlData ' commented
Of course. I posted the code. You can modify any way you like.
I did feel a disturbance in the force, though. All my BS2's started pointing south!!!
Also would we need to change INDEPDENT WHEELS to MECANNUM WHEELS?
Yes, you could send pulses to the pins that would normally read the RC receiver. Here's the list of constants from the controller object.
The "#0" means to set the list to incrementing values starting with zero.
Of the channels listed, you'd want to use x (channel 1), y (2), and rotate (3). The x is the aileron control, y is elevator and rotate is rudder.
Yes, you want to use the mecanum setting. You also need to change the input type in the header file from:
To:
Also is there anything else we would need to change ? can't seem to figure out why were not getting any movement.
repeat
if Pst.CharIn == "S"
Bot.Straight(500)
So I added this to main to wait for a command from the arduino and it works reliable so far. I am thinking of adding a case statement when I add in more commands such as move left move right rotate etc. The problem I am having is writing a new function to add to the obj Bot. I see Straight is written like this
PUB Straight(localSpeed)
globalSpeed := localSpeed
command := STRAIGHT_CMD
But i dont quite understand where the wheels are actually being set, so if I wanted to write a left and right function where would I need to access or send the speeds?
I think I may have figured it out this is where the actual settings is made. So from mainloop pub straight is called passed local speed then global speed is set and command is set to straight cmd then case statement chooses priv straight which then sets the motor speeds?
PRI StraightPrivate
repeat result from 0 to HIGHEST_MOTOR_ID
long[targetPtr][result] := globalSpeed
SetSpeedsPrivate
command := INDIVIDUAL_CMD
So I was thinking
PUB Right(localspeed)
globalSpeed := localSpeed
command := RIGHT_CMD
PRI RightPrivate
repeat result from 0 to HIGHEST_MOTOR_ID
//This part I am not sure how to set the individual motors I would need Front left and back left motors going away from each other 0700 1-700 and then front right and back right going towards each other 2-700 3700
long[targetPtr][result] := globalSpeed
SetSpeedsPrivate
command := INDIVIDUAL_CMD
Very good.
The code has gone through several modifications so there is some redundancy. Both the "Bot" object and the "Control" object (as well as the top object can all change the speed of the wheels.
The various ways of changing the speed always ends up changing the global array in the top object "targetSpeed". The address of this array gets passed to the other objects so they can modify it directly.
I think your idea of adding additional "case" options is a good one. That's the way I'd do it.
The Mecanum equations are in the "Control" object. I see there's a public method for setting the direction and speed.
By passing the method your desired speed and direction of travel, it will compute the four wheel speeds for you (zero degrees is to the right and 90 degrees is straight ahead). Unfortunately I don't see a method for setting the rotation.
If you use the "Control" object in this way, you'll need to change the input type back to PC only.
What would be your desired interface? If you limit yourself to serial commands, what would you want the program to be able to do?
I'm working on this program right now to improve its low speed control and I could add a few features to make it easier to control through a serial connection. So what kind of commands would you want it to accept? Not that I'm making promises to include these features but I might and I might make changes you suggest if they seem like a good features to add.
I was thinking it would be good to be able to send a command to set the speed, direction and rotation. There's already a stop command.
Let me know what commands you'd like it to be able to accept.