theres one thing thats faulty and that is sometimes the wheels just stop moving forever until i turn the robot off and then on again.
The first thing to check is to see if resetting the Activity Board fixes the glitch. If it requires a full power cycle, then it might be a problem with the RC receiver. Additional debugging could be done by leaving the USB cable attached and monitoring the output.
I don't have a WX version of the Activity Board so I'm not sure if the debugging could be done wirelessly. I imagine so but I'm not sure how this is done.
You'd want to see if the following values change as you move the joystick.
"loops", "Aileron" and "Elevator".
Thanks for posting the video. Your robot looks fantastic.
You'll likely discover this sooner than later but ultrasound sensors don't pickup soft objects well. Ultrasound can also bounce away from the sensor if they hit a hard smooth object at a glancing angle.
IR sensors compliment ultrasound sensors really well. IR pick up soft objects just fine. The combination of IR and ultrasound make a good object avoidance system.
Ken was going to add the DHB 10 firmware without its fault codes to its product page. Im not sure hes done that yet. He mentioned that the firmware was buggy and they hadnt figured out why but this should fix the issue. You just would need to update the board using a prop plug. Hopefully you soldered on the header before installing it. I had to disassemble mine and do it. Also added the fan header though Im not using it yet. edit...The product page hasnt been updated yet with the other firmware.
The original Eddie code had a timeout period. This had to be disabled if the board wasn't receiving continuous updates from a PC.
reinaldo, are you okay with using Spin code in the DHB-10 board? You'd use The Propeller Tool and a Prop Plug to load the new code into the DHB-10. If the code in the DHB-10 is shutting off, I may be able to fix it. As I mentioned earlier, I worked a lot with earlier versions of Arlo code. I think I'd be able to modify the DHB-10 code if it's the source of your problem (motors stopping after they've been on a while).
well it seemed to work with another code so i think it might just be a software thing but i got the prop plug and im good with spin i can give it a whirl and also the lights are not flashing so like i said i think its the way the code is written for the aileron and elevator command. i sent a message to you directly.
I've had a couple glitches with my robot where the motors wouldn't turn but I'm not sure if it's something I've done verses an error in the hardware/software. I'll try to find time to experiment a bit more with this today.
in the code when i start the robot it spins the wheels on start up without remote being on which is not really a big deal but all the sensors don't really stop the robot except ping 16.
by the way lol weird question is there a way to see the terminal using some type of screen without being connected to the computer like an lcd or some kind of screen.
is there a way to see the terminal using some type of screen without being connected to the computer like an lcd or some kind of screen.
Yes. A serial LCD is one easy way to do this. There are lots of different options besides the ones Parallax sells.
Most serial LCD use a few command codes for formatting but these commands are generally pretty easy to use.
Another good option is to have the serial information sent over a wireless device. If your computer has Bluetooth, you can use a small Bluetooth module as a link between the computer and the robot. Parallax Serial Terminal doesn't always behave well with Bluetooth so I often use TeraTerm.
I generally use HC-05 Bluetooth modules since these devices can be used as both a slave and master. It's possible for two HC-05 modules to communicate. HC-06 is another common module but two HC-06 modules can't communicate with each other (at least as far as I know).
Thanks @"Duane Degn" for helping reinaldo along. He's developing some robotic skills and is picking up everything we've shared so far. You have a productive approach and we appreciate it.
all the sensors don't really stop the robot except ping 16.
There's a problem with the way you are storing Ping values. Your pingDistance array should have an element for each sensor. Rather than having two elements in the array, you need five elements. The method "FindClosestPing" needs to be adapted to account for the additional sensors. The logic of what to do with the Ping information will need to be changed as well.
You probably only need to worry about the rear Ping when the robot is backing up. You can have one set of conditions when the robot is moving forward and another set of checks when the robot is backing up. You'll need to decide what you want the robot to do in various circumstances.
If you have two Ping sensors on the back of the robot, you could probably use something similar to the original two Ping code I shared. The forward code will need to be modified to account for the third forward looking Ping (assuming you have three facing forward.
As a start, list the Ping pin numbers and where the Ping sensors is located. I'll try to modify the code a bit to show you what I have in mind.
I see you have five Pings across the front. As you mentioned, the Blockly program doesn't use these Pings properly.
I tried to edit the Blockly program but the cloud interface was infuriatingly slow. I've run into similar problems with other block based programming tools like MIT's App Inventor 2. When a program becomes large, the interface becomes very slow and awkward.
I saved the program locally and tried to use Solo Blockly but when I opened the program locally, most of the arrays reverted to "list" as the array name. A bunch of other problems arose as I tried to edit the program loclly.
I don't know if Blockly is just behaving poorly for me or if this a common problem for other Blockly users but I'm finding Blockly unusable for large programs.
If you want to give Spin a try, I'm willing to help you convert and improve the program. I've done a bunch of work in Spin using Arlo hardware. I think you could get meaningful data from your encoders if you wanted to switch to Spin.
There's also a lot of code in C available for the Arlo hardware. Since Blockly can output C code, you'd be able to convert the program to C with a click of the mouse.
I don't think it would take long to translate your Blockly to Spin so don't let the easy of converting to C be the deciding factor. Either language would likely be an improvement over Blockly when your program gets larger.
If I'm wrong about the limitations of Blockly, I hope someone lets me know. I think Blockly is fun to use but I've only found it useful for relatively small programs.
Hey Duane I noticed the same thing when the program in blockly got larger it started getting buggy but yes I would love to work in spin with you to create a beautiful program. Thanks again I have tv option on the wx boe could I use that as an option to display and project the readings from the terminal to a tv.
I've been trying to figure out what a good starting point for an RC controlled Arlo would be. A lot will depend on what you're using for motor control. In another post, you mentioned using a Cytron board to control the motors. Would you please tell me the exact Cytron board you are using?
If you the Cytron uses RC pulses for control, then the Eddie Firmware for Propeller Activity Board with HB-25 Controllers might be a good place to start. There's a link to this firmware near the bottom of this linked post. This firmware uses Eddie commands plus a few I added. The commands I added are listed in the comments near the beginning of the top object's code. This code does NOT use RC pulses for input.
While the above mentioned firmware worked reasonably well, I didn't really like the low speed performance. I'm working on some code which measures the time between encoder transitions rather than encoder transitions per unit time. I hopeful this will have better low speed performance.
If you don't mind testing the low speed code, I'd like your feedback on it. I'll include input from RC pulses so hopefully it will be relatively easy for you to use.
There will likely be some PID parameters you'll need to adjust. I'll provide instructions on how to adjust these parameters.
It will be really helpful if you answer all the questions I ask. Each question will end with a question mark so they should be obvious. Besides the question about the motor controller above, I'd also like to know about your RC gear.
What RC radio are you use? How many channels does it have? How many channels do you plan to use to control the robot?
Hopefully I'll have some Spin code modified to use RC input in the next couple of days.
Comments
It would be a lot of fun to see more photos and/or video.
I hope you keep us updated on your robot.
Thanks for sharing the video.
I don't have any FlySky gear but FrSky and Spektrum use 3.3V logic. I'm not positive but I think you're safe without using resistors.
The first thing to check is to see if resetting the Activity Board fixes the glitch. If it requires a full power cycle, then it might be a problem with the RC receiver. Additional debugging could be done by leaving the USB cable attached and monitoring the output.
I don't have a WX version of the Activity Board so I'm not sure if the debugging could be done wirelessly. I imagine so but I'm not sure how this is done.
You'd want to see if the following values change as you move the joystick.
"loops", "Aileron" and "Elevator".
Thanks for posting the video. Your robot looks fantastic.
IR sensors compliment ultrasound sensors really well. IR pick up soft objects just fine. The combination of IR and ultrasound make a good object avoidance system.
reinaldo, are you okay with using Spin code in the DHB-10 board? You'd use The Propeller Tool and a Prop Plug to load the new code into the DHB-10. If the code in the DHB-10 is shutting off, I may be able to fix it. As I mentioned earlier, I worked a lot with earlier versions of Arlo code. I think I'd be able to modify the DHB-10 code if it's the source of your problem (motors stopping after they've been on a while).
Here's a link to the product guide.
I've had a couple glitches with my robot where the motors wouldn't turn but I'm not sure if it's something I've done verses an error in the hardware/software. I'll try to find time to experiment a bit more with this today.
im trying to use five pings to stop the robot from crashing into an object al five pings are in front of the robot none in the back
It looked like you had your robot was doing what you want already.
What's different now? Is it just the number of Ping sensors?
You mentioned wanting to add sensors to the back of the robot. Is that still the plan?
Does this happen only if the transmitter isn't on? Or does it spin on start up even if the transmitter is on?
Yes. A serial LCD is one easy way to do this. There are lots of different options besides the ones Parallax sells.
Most serial LCD use a few command codes for formatting but these commands are generally pretty easy to use.
Another good option is to have the serial information sent over a wireless device. If your computer has Bluetooth, you can use a small Bluetooth module as a link between the computer and the robot. Parallax Serial Terminal doesn't always behave well with Bluetooth so I often use TeraTerm.
I generally use HC-05 Bluetooth modules since these devices can be used as both a slave and master. It's possible for two HC-05 modules to communicate. HC-06 is another common module but two HC-06 modules can't communicate with each other (at least as far as I know).
Go get 'em, reinaldo!
Ken Gracey
There's a problem with the way you are storing Ping values. Your pingDistance array should have an element for each sensor. Rather than having two elements in the array, you need five elements. The method "FindClosestPing" needs to be adapted to account for the additional sensors. The logic of what to do with the Ping information will need to be changed as well.
You probably only need to worry about the rear Ping when the robot is backing up. You can have one set of conditions when the robot is moving forward and another set of checks when the robot is backing up. You'll need to decide what you want the robot to do in various circumstances.
If you have two Ping sensors on the back of the robot, you could probably use something similar to the original two Ping code I shared. The forward code will need to be modified to account for the third forward looking Ping (assuming you have three facing forward.
As a start, list the Ping pin numbers and where the Ping sensors is located. I'll try to modify the code a bit to show you what I have in mind.
Agreed. It's a very cool robot.
Thanks for posting the video Reinaldo.
I see you have five Pings across the front. As you mentioned, the Blockly program doesn't use these Pings properly.
I tried to edit the Blockly program but the cloud interface was infuriatingly slow. I've run into similar problems with other block based programming tools like MIT's App Inventor 2. When a program becomes large, the interface becomes very slow and awkward.
I saved the program locally and tried to use Solo Blockly but when I opened the program locally, most of the arrays reverted to "list" as the array name. A bunch of other problems arose as I tried to edit the program loclly.
I don't know if Blockly is just behaving poorly for me or if this a common problem for other Blockly users but I'm finding Blockly unusable for large programs.
If you want to give Spin a try, I'm willing to help you convert and improve the program. I've done a bunch of work in Spin using Arlo hardware. I think you could get meaningful data from your encoders if you wanted to switch to Spin.
There's also a lot of code in C available for the Arlo hardware. Since Blockly can output C code, you'd be able to convert the program to C with a click of the mouse.
I don't think it would take long to translate your Blockly to Spin so don't let the easy of converting to C be the deciding factor. Either language would likely be an improvement over Blockly when your program gets larger.
If I'm wrong about the limitations of Blockly, I hope someone lets me know. I think Blockly is fun to use but I've only found it useful for relatively small programs.
If you the Cytron uses RC pulses for control, then the Eddie Firmware for Propeller Activity Board with HB-25 Controllers might be a good place to start. There's a link to this firmware near the bottom of this linked post. This firmware uses Eddie commands plus a few I added. The commands I added are listed in the comments near the beginning of the top object's code. This code does NOT use RC pulses for input.
While the above mentioned firmware worked reasonably well, I didn't really like the low speed performance. I'm working on some code which measures the time between encoder transitions rather than encoder transitions per unit time. I hopeful this will have better low speed performance.
If you don't mind testing the low speed code, I'd like your feedback on it. I'll include input from RC pulses so hopefully it will be relatively easy for you to use.
There will likely be some PID parameters you'll need to adjust. I'll provide instructions on how to adjust these parameters.
It will be really helpful if you answer all the questions I ask. Each question will end with a question mark so they should be obvious. Besides the question about the motor controller above, I'd also like to know about your RC gear.
What RC radio are you use? How many channels does it have? How many channels do you plan to use to control the robot?
Hopefully I'll have some Spin code modified to use RC input in the next couple of days.