Just writing to provide some feedback. I install the Eddie program with your firmware and it works great. Thank you for all your effort.
Even though it's works fine in the direct mode, I couldn't made it works with the obstacle avoidance. In with pins should I connect the sensors? Any ideas?
Thank you.
The program itself doesn't avoid obstacles. The PC side of the system needs to send PING commands and use the data received to figure out if there's an obstacle or not.
I'm not much of a PC programer (any more) and I haven't tested the Eddie firmware with any of the PC side software. I've only used the Parallax Serial Terminal.exe to communicate with the Propeller.
There's a command "SPNG" to set up Ping sensors but IMO, it's probably easier to modify the header file and add the I/O pins used with the Ping sensors.
If you're using the original Eddie control board, you want to modify the file "HeaderEddieHbridgeEncoders.spin."
' Pin assignments
' Ping))) sensors
PING_0 = 0 '' User changeable
PING_1 = 1 '' User changeable
PINGS_IN_USE = 2 '' User changeable
INITIAL_PING = |< PING_0 | |< PING_1 '' User changeable
The program uses the constant "INITIAL_PING" to know which I/O pins have Ping sensors attached.
If you have a different number of Ping sensors, let me know how many you have and to which I/O pins they're connected and I will show you how to modify this constant to include the I/O pins you use.
As I mentioned, it should be possible to add Ping sensors with the "SPNG" command. I confess to not being sure if I tested this command or not I don't think I changed the command from the original version of the code. I had Ping sensors attached to P0 and P1 and always used the hardcoded values to set which pins the program should monitor.
The Ping section of the code has been heavily modified. My robot was experiencing a lot of interference between the two Ping sensors when using the original code. I'm pretty sure the interference was caused by having all the sensors triggered together. I modified the code to continuously monitor the Ping sensors (unless paused with PNGP). When the "PING" command is received, the program returns the last readings received from the sensors.
The idea behind returning the previous sensor readings rather than waiting for fresh data, as the previous version had, was to compensate for the increased amount to time it took to read from all the sensors. My modified PING code added a delay between each sensor reading. If a lot of Ping sensors were used, this delay could be significant. I thought returning the previous readings was a good compromise between accurate readings and timely data. I personally think eliminating the problem of inter-Ping interference was worth spending more time reading from the sensors.
If you think the SPNG or other Ping related commands aren't working correctly, let me know and I'll make sure and test the code with my hardware.
The program itself doesn't avoid obstacles. The PC side of the system needs to send PING commands and use the data received to figure out if there's an obstacle or not.
I'm not much of a PC programer (any more) and I haven't tested the Eddie firmware with any of the PC side software. I've only used the Parallax Serial Terminal.exe to communicate with the Propeller.
There's a command "SPNG" to set up Ping sensors but IMO, it's probably easier to modify the header file and add the I/O pins used with the Ping sensors.
If you're using the original Eddie control board, you want to modify the file "HeaderEddieHbridgeEncoders.spin."
' Pin assignments
' Ping))) sensors
PING_0 = 0 '' User changeable
PING_1 = 1 '' User changeable
PINGS_IN_USE = 2 '' User changeable
INITIAL_PING = |< PING_0 | |< PING_1 '' User changeable
The program uses the constant "INITIAL_PING" to know which I/O pins have Ping sensors attached.
If you have a different number of Ping sensors, let me know how many you have and to which I/O pins they're connected and I will show you how to modify this constant to include the I/O pins you use.
As I mentioned, it should be possible to add Ping sensors with the "SPNG" command. I confess to not being sure if I tested this command or not I don't think I changed the command from the original version of the code. I had Ping sensors attached to P0 and P1 and always used the hardcoded values to set which pins the program should monitor.
The Ping section of the code has been heavily modified. My robot was experiencing a lot of interference between the two Ping sensors when using the original code. I'm pretty sure the interference was caused by having all the sensors triggered together. I modified the code to continuously monitor the Ping sensors (unless paused with PNGP). When the "PING" command is received, the program returns the last readings received from the sensors.
The idea behind returning the previous sensor readings rather than waiting for fresh data, as the previous version had, was to compensate for the increased amount to time it took to read from all the sensors. My modified PING code added a delay between each sensor reading. If a lot of Ping sensors were used, this delay could be significant. I thought returning the previous readings was a good compromise between accurate readings and timely data. I personally think eliminating the problem of inter-Ping interference was worth spending more time reading from the sensors.
If you think the SPNG or other Ping related commands aren't working correctly, let me know and I'll make sure and test the code with my hardware.
Hi Duane,
Thank you for your help.
I currentily have two ultrasonic sensor connected to the pins 5 and 6. I also, have three infrared sensor connected to the pins 10, 11 and 12. I would like to use there to avoid obstacles like the original eddie do. Could you help me please.
Another thing I would like to have is a way to send the moviment commands from the keyboard in the computer. Could you also help me with that.
I currentily have two ultrasonic sensor connected to the pins 5 and 6.
Are these Ping sensors? If so then you should modify the constants to indicate which I/O pins you're using with the Ping sensors.
PING_0 = [B]5[/B] '' User changeable
PING_1 = [B]6[/B] '' User changeable
P5 and P6 both have current limiting resistors so it should be fine to use these I/O pins.
The above code starts on line # 48 of the file "HeaderEddieHbridgeEncoders." This is assuming you're using the original Eddie control board. Are you using the original Eddie board?
I also, have three infrared sensor connected to the pins 10, 11 and 12.
I thought P10 and P11 were used for the encoders? Which board are you using?
Depending on what kind of sensors you have, it might not be a good idea to have them connected directly to the Propeller. Many IR sensors can output up to 5V on the signal line. This higher voltage can damage the Propeller unless current limiting resistors are used. If you have an Eddie control board, P10 and P11 both are protected with 4.7K ohm resistors but P12 is not protected.
Depending on which sensors you're using, you may want to connect the sensors to the ADC ports and not to the Propeller's I/O pins. What model of IR sensors are you using?
To read the IR sensors (assuming they output an analog signal) you'll need to query the ADC with the "ADC" command. The PC program will need to read these values and perform the appropriate calculations to translate the voltage readings into distances.
I would like to use there to avoid obstacles like the original eddie do.
As I understand things, the original Eddie required a PC program to command the Propeller and to receive data back from the Propeller. The Propeller didn't take care of any of the obstacle avoidance directly.
Another thing I would like to have is a way to send the moviment commands from the keyboard in the computer.
While the firmware uses an interface which will work from a PC terminal, I think it's mainly intended to be used with a program running on the PC which generates the commands automatically. I haven't used the PC side of the Eddie software. I tested the Eddie commands using a terminal window (Parallax Serial Terminal.exe). Since I was using a terminal window as the interface program, I added a few commands to make it easier to type in commands.
The command "decin 1" will turn on the firmware's ability to receive base ten input rather than relying on hexadecimal input.
Likewise the command "decout 1" will switch the output from the Propeller to base ten instead of hexadecimal.
I go into some additional detail about using the firmware with a terminal program in post #22 of this thread.
First I am using the Propeller Activity Board with HB-25 motor controller running your firmware. It's works great. I have 2 ultrasonic sensors (https://www.parallax.com/product/28015) now connected to pins 0 and 1. It's works great. I also have 3 IR sensors (https://www.parallax.com/product/28995) now connected to pins 5, 6 and 7. Finally, I always use it connected to a computer with the kinect v1 attached.
My problems are:
1. The original Eddie software with obstacle avoidance is not work properly. I think it's because the 3 IR sensor are not been recognized.
2. I make no idea how to send commands by the keyboard (like: pressing 8 to go forward...) from the computer connected to the robot in order to move it around.
Could you help me with that.
I also have one more question, if I connect the Kinect v2 to the computer it's going to work?
I am looking to try out your code, I have pulled it from GITHUB and I am going thru it.
I think I have found where to hook the PINGS (0,1) but I have not seen how to hook up the HB25 or the encoders.
Since I decided to made the new features available for use with the original Eddie hardware, I moved board specific constants to a header file. This allows the same main program to work with both hardware configurations.
Since you mention HB-25 motor controllers, I assume you're also using a Propeller Activity Board (PAB). The main archive you want is the "EddieActivityBoard - Archive. . ." Within this archive (and available separately) is the object "HeaderEddieAbHb25Encoders.spin." The I/O pins used on the Activity Board are listed at the top of this object.
IIRC, The left encoder connects to pins 14 and 15. The right encoder connects with 16 and 17. The constants "ENABLE_x" identify the I/O pins used with the HB-25 controllers. I tried to keep the naming convention the same as the original Eddie code.
Also, once the firmware is loaded will/does this talk to ROS using the eddie ROS stack ?
The firmware should interface with the ROS software the same way the original Eddie firmware had. I haven't tried ROS myself.
As I mentioned a couple of posts ago, I added some commands to the firmware which would allow one to more easily interface with the Propeller through a terminal program like Parallax Serial Terminal. I gave some instructions on using these commands in post #22.
I'm personally not a fan of using PCs with robots. I may use a small SBC like a Raspberry Pi sometime but for now, I prefer to use the Propeller as the main controller on my robots. To use the Eddie firmware without a PC (not that you're asking) I took two approaches. One approach was to add a "demo" command to the firmware which would run through a set of commands stored in the DAT section. I discuss how I did this in post #41 of this thread.
The other approach to using the firmware in a Propeller only robot is to use the various methods of the firmware as a starting point and write a program which uses these methods to control the robot. I don't presently have a good example of this technique. I have several variations of a program "Cleaver" I use in my robot but most of these variations have been used to test various sensors. I don't have an example of a program which provides autonomous operation.
Back to ROS, as I mentioned, the firmware should work with ROS. I hope you let me know how is works if you try it. I should really find a PC to load ROS onto so I can test this myself but I'm just not very enthusiastic about trying to program a PC rather than a Propeller.
Comments
The program itself doesn't avoid obstacles. The PC side of the system needs to send PING commands and use the data received to figure out if there's an obstacle or not.
I'm not much of a PC programer (any more) and I haven't tested the Eddie firmware with any of the PC side software. I've only used the Parallax Serial Terminal.exe to communicate with the Propeller.
There's a command "SPNG" to set up Ping sensors but IMO, it's probably easier to modify the header file and add the I/O pins used with the Ping sensors.
If you're using the original Eddie control board, you want to modify the file "HeaderEddieHbridgeEncoders.spin."
The program uses the constant "INITIAL_PING" to know which I/O pins have Ping sensors attached.
If you have a different number of Ping sensors, let me know how many you have and to which I/O pins they're connected and I will show you how to modify this constant to include the I/O pins you use.
As I mentioned, it should be possible to add Ping sensors with the "SPNG" command. I confess to not being sure if I tested this command or not I don't think I changed the command from the original version of the code. I had Ping sensors attached to P0 and P1 and always used the hardcoded values to set which pins the program should monitor.
The Ping section of the code has been heavily modified. My robot was experiencing a lot of interference between the two Ping sensors when using the original code. I'm pretty sure the interference was caused by having all the sensors triggered together. I modified the code to continuously monitor the Ping sensors (unless paused with PNGP). When the "PING" command is received, the program returns the last readings received from the sensors.
The idea behind returning the previous sensor readings rather than waiting for fresh data, as the previous version had, was to compensate for the increased amount to time it took to read from all the sensors. My modified PING code added a delay between each sensor reading. If a lot of Ping sensors were used, this delay could be significant. I thought returning the previous readings was a good compromise between accurate readings and timely data. I personally think eliminating the problem of inter-Ping interference was worth spending more time reading from the sensors.
If you think the SPNG or other Ping related commands aren't working correctly, let me know and I'll make sure and test the code with my hardware.
Hi Duane,
Thank you for your help.
I currentily have two ultrasonic sensor connected to the pins 5 and 6. I also, have three infrared sensor connected to the pins 10, 11 and 12. I would like to use there to avoid obstacles like the original eddie do. Could you help me please.
Another thing I would like to have is a way to send the moviment commands from the keyboard in the computer. Could you also help me with that.
Appreciated.
Are these Ping sensors? If so then you should modify the constants to indicate which I/O pins you're using with the Ping sensors.
P5 and P6 both have current limiting resistors so it should be fine to use these I/O pins.
The above code starts on line # 48 of the file "HeaderEddieHbridgeEncoders." This is assuming you're using the original Eddie control board. Are you using the original Eddie board?
I thought P10 and P11 were used for the encoders? Which board are you using?
Depending on what kind of sensors you have, it might not be a good idea to have them connected directly to the Propeller. Many IR sensors can output up to 5V on the signal line. This higher voltage can damage the Propeller unless current limiting resistors are used. If you have an Eddie control board, P10 and P11 both are protected with 4.7K ohm resistors but P12 is not protected.
Depending on which sensors you're using, you may want to connect the sensors to the ADC ports and not to the Propeller's I/O pins. What model of IR sensors are you using?
To read the IR sensors (assuming they output an analog signal) you'll need to query the ADC with the "ADC" command. The PC program will need to read these values and perform the appropriate calculations to translate the voltage readings into distances.
As I understand things, the original Eddie required a PC program to command the Propeller and to receive data back from the Propeller. The Propeller didn't take care of any of the obstacle avoidance directly.
While the firmware uses an interface which will work from a PC terminal, I think it's mainly intended to be used with a program running on the PC which generates the commands automatically. I haven't used the PC side of the Eddie software. I tested the Eddie commands using a terminal window (Parallax Serial Terminal.exe). Since I was using a terminal window as the interface program, I added a few commands to make it easier to type in commands.
The command "decin 1" will turn on the firmware's ability to receive base ten input rather than relying on hexadecimal input.
Likewise the command "decout 1" will switch the output from the Propeller to base ten instead of hexadecimal.
I go into some additional detail about using the firmware with a terminal program in post #22 of this thread.
http://forums.parallax.com/showthread.php/158030-Open-Propeller-Project-8-Eddie-Firmware-Ported-to-Propeller-Activity-Board?p=1302947&viewfull=1#post1302947
Edit(4/19/20): Use code linked from this post.
Let me try to express myself better.
First I am using the Propeller Activity Board with HB-25 motor controller running your firmware. It's works great. I have 2 ultrasonic sensors (https://www.parallax.com/product/28015) now connected to pins 0 and 1. It's works great. I also have 3 IR sensors (https://www.parallax.com/product/28995) now connected to pins 5, 6 and 7. Finally, I always use it connected to a computer with the kinect v1 attached.
My problems are:
1. The original Eddie software with obstacle avoidance is not work properly. I think it's because the 3 IR sensor are not been recognized.
2. I make no idea how to send commands by the keyboard (like: pressing 8 to go forward...) from the computer connected to the robot in order to move it around.
Could you help me with that.
I also have one more question, if I connect the Kinect v2 to the computer it's going to work?
Thank you very much.
Don't connect these to the Propeller directly! They can damage the Propeller.
I'll reply in more detail shortly. Just disconnect these for now.
I am looking to try out your code, I have pulled it from GITHUB and I am going thru it.
I think I have found where to hook the PINGS (0,1) but I have not seen how to hook up the HB25 or the encoders.
Also, once the firmware is loaded will/does this talk to ROS using the eddie ROS stack ?
Thanks,
JT
Since I decided to made the new features available for use with the original Eddie hardware, I moved board specific constants to a header file. This allows the same main program to work with both hardware configurations.
Since you mention HB-25 motor controllers, I assume you're also using a Propeller Activity Board (PAB). The main archive you want is the "EddieActivityBoard - Archive. . ." Within this archive (and available separately) is the object "HeaderEddieAbHb25Encoders.spin." The I/O pins used on the Activity Board are listed at the top of this object.
IIRC, The left encoder connects to pins 14 and 15. The right encoder connects with 16 and 17. The constants "ENABLE_x" identify the I/O pins used with the HB-25 controllers. I tried to keep the naming convention the same as the original Eddie code.
The firmware should interface with the ROS software the same way the original Eddie firmware had. I haven't tried ROS myself.
As I mentioned a couple of posts ago, I added some commands to the firmware which would allow one to more easily interface with the Propeller through a terminal program like Parallax Serial Terminal. I gave some instructions on using these commands in post #22.
I'm personally not a fan of using PCs with robots. I may use a small SBC like a Raspberry Pi sometime but for now, I prefer to use the Propeller as the main controller on my robots. To use the Eddie firmware without a PC (not that you're asking) I took two approaches. One approach was to add a "demo" command to the firmware which would run through a set of commands stored in the DAT section. I discuss how I did this in post #41 of this thread.
The other approach to using the firmware in a Propeller only robot is to use the various methods of the firmware as a starting point and write a program which uses these methods to control the robot. I don't presently have a good example of this technique. I have several variations of a program "Cleaver" I use in my robot but most of these variations have been used to test various sensors. I don't have an example of a program which provides autonomous operation.
Back to ROS, as I mentioned, the firmware should work with ROS. I hope you let me know how is works if you try it. I should really find a PC to load ROS onto so I can test this myself but I'm just not very enthusiastic about trying to program a PC rather than a Propeller.