Derrick BommaritoThings I've Built
BArd
A small differential drive robot designed for entry into the Trinity Firefighting competition. The robot was controlled via ROS running on a beagleboard rev C4 with a custom I/O expansion board. This was my first foray into designing fabbed PCBs
Guus van der SluijsShare this profile
ShareBits
tommytwoeyes
wrote 03/07/2014 at 20:54
•
point
Derrick,
Thanks for looking into that for me. My understanding of ROS is so elementary that I didn't even realize there was an alternative to ros_control, or that you could have a single ROS node that communicates with another robot component that isn't using ROS.
I don't really have a specific use problem I'm trying to solve with the rover. I'm just eager to learn more about robotics and was planning to use the rover as a means to learn about algorithms used in robotic navigation, and to learn ROS in the process. I built a couple of (very) simple rovers with Arduino clones but quickly realized the constraints its limited memory and processor have on a robot's capabilites .
I also have a limited budget, so the rover's functionality will be determined to a large degree by the sensors, actuators, components, and chassis (plural) I have on hand. I do want it to be at least semi-autonomous, so with that goal and the budget limitation in mind, I was thinking I'd design it to literally rove around my apartment, with the ability to avoid obstacles. Not too interesting, I know, but as I learn more, I'd like to add a webcam to recognize objects and follow them.
The scenarios you described are more or less what I had in mind, although I didn't articulate it as well as you did. I'd like to use ROS on the Pi to make decisions based on data it periodically either actively polls for or passively receives from the ATmega, while the ATmega constantly controls the sensors and actuators (or manages other MCUs that control them - I don't want to add needless complexity; I'm just not sure how much the 1284 or 2560 can handle on its own).
Again, I appreciate your effort to help me and am looking forward to your I2C examples.
I was unsure of the physical communication bus to use, but based on your advice I'll use I2C, because I also want to reserve as many of the Pi's GPIO pins as possible, and its ability to connect such a large number of devices sounds like it will make it easier to increase the rover's capabilites by adding nodes in the future.
Thanks for looking into that for me. My understanding of ROS is so elementary that I didn't even realize there was an alternative to ros_control, or that you could have a single ROS node that communicates with another robot component that isn't using ROS.
I don't really have a specific use problem I'm trying to solve with the rover. I'm just eager to learn more about robotics and was planning to use the rover as a means to learn about algorithms used in robotic navigation, and to learn ROS in the process. I built a couple of (very) simple rovers with Arduino clones but quickly realized the constraints its limited memory and processor have on a robot's capabilites .
I also have a limited budget, so the rover's functionality will be determined to a large degree by the sensors, actuators, components, and chassis (plural) I have on hand. I do want it to be at least semi-autonomous, so with that goal and the budget limitation in mind, I was thinking I'd design it to literally rove around my apartment, with the ability to avoid obstacles. Not too interesting, I know, but as I learn more, I'd like to add a webcam to recognize objects and follow them.
The scenarios you described are more or less what I had in mind, although I didn't articulate it as well as you did. I'd like to use ROS on the Pi to make decisions based on data it periodically either actively polls for or passively receives from the ATmega, while the ATmega constantly controls the sensors and actuators (or manages other MCUs that control them - I don't want to add needless complexity; I'm just not sure how much the 1284 or 2560 can handle on its own).
Again, I appreciate your effort to help me and am looking forward to your I2C examples.
I was unsure of the physical communication bus to use, but based on your advice I'll use I2C, because I also want to reserve as many of the Pi's GPIO pins as possible, and its ability to connect such a large number of devices sounds like it will make it easier to increase the rover's capabilites by adding nodes in the future.
tommytwoeyes
wrote 03/07/2014 at 04:18
•
point
Your RoPI board and robot projects all are pretty awesome. Are you planning to sell RoPI boards once you finalize the design?
I am trying to learn ROS and am in the process of planning a small rover, for which I'm planing to use a distributed architecture, with a Raspberry Pi as the main controller (i.e. for navigation, potential image processing - those things are still TBD) and one or more AVR microcontrollers for controlling the motors, sensor nodes, etc, possibly with another AVR or an Ardunio Mega I have as a sort of gateway between the Pi and the various AVR nodes. But I am somewhat perplexed in trying to decide how the Pi should communicate with the gateway node and/or the other AVRs within the robot's internal network.
If you don't mind if I ask, how did you solve that with the ROS robots you built? I read that Hydro now has a ros_control package, but I have no clue which physical connection method (i2c, SPI, etc) is ideal in a relatively small robot.
Thanks,
Tom
I am trying to learn ROS and am in the process of planning a small rover, for which I'm planing to use a distributed architecture, with a Raspberry Pi as the main controller (i.e. for navigation, potential image processing - those things are still TBD) and one or more AVR microcontrollers for controlling the motors, sensor nodes, etc, possibly with another AVR or an Ardunio Mega I have as a sort of gateway between the Pi and the various AVR nodes. But I am somewhat perplexed in trying to decide how the Pi should communicate with the gateway node and/or the other AVRs within the robot's internal network.
If you don't mind if I ask, how did you solve that with the ROS robots you built? I read that Hydro now has a ros_control package, but I have no clue which physical connection method (i2c, SPI, etc) is ideal in a relatively small robot.
Thanks,
Tom
Derrick Bommarito
wrote 03/07/2014 at 04:54
•
point
I won't be manufacturing any boards for anyone but all of the plans, BoM, and software will be open source. I will be seeing if Sparkfun (or similar) are interested in picking it up. As stated on the RoPi page, I've just ordered the first set of prototypes but I've already made some design changes for the next set of prototypes. Knowing me, finalizing a design could take a while!
I'm so out of touch with ROS. The last version I used to any extent was Fuerte and a lot has changed since then. Back then it was rosserial. Back then installing ROS from source was also a lot easier.
What are you planning on doing with the rover? What you're planning to do sounds like overkill and will most likely result in making more work for yourself than you need.
My board connects the ATmega to the Pi via the I2C bus. I did this for a few reasons:
1. I wanted to leave the SPI and other GPIO pins free so that other Pi expansions could still be used. I2C allows up to 128 devices per bus.
2. I already have a decent idea of how I'll be implementing the firmware for the ATmega and will not need asynchronous communication. The ATmega will continue churning away at its tasks with the Pi periodically reading out sensor values and updating parameters and outputs.
I'm so out of touch with ROS. The last version I used to any extent was Fuerte and a lot has changed since then. Back then it was rosserial. Back then installing ROS from source was also a lot easier.
What are you planning on doing with the rover? What you're planning to do sounds like overkill and will most likely result in making more work for yourself than you need.
My board connects the ATmega to the Pi via the I2C bus. I did this for a few reasons:
1. I wanted to leave the SPI and other GPIO pins free so that other Pi expansions could still be used. I2C allows up to 128 devices per bus.
2. I already have a decent idea of how I'll be implementing the firmware for the ATmega and will not need asynchronous communication. The ATmega will continue churning away at its tasks with the Pi periodically reading out sensor values and updating parameters and outputs.
Derrick Bommarito
wrote 03/07/2014 at 15:35
•
point
Tom,
I've taken a quick look over the ROS site again, and rosserial is still there and control seems to be for more advanced systems. (Like the arm and locomotion on their PR2 robot). Personally, I would stick to using your own hardware and software interfacing to any embedded MCUs. While rosserial certainly evens the programming field across the platforms, it adds a LOT of overhead to the ATmega and things that used to work properly may no longer work as more protocol control and memory management by rosserial eats up more and more CPU time. (Rosserial on a motor controller expecting high speed quadrature encoders = many headaches)
Write a ROS node that runs on the Pi and handles writing and reading all of the appropriate data to/from the ATmega/Arduino. Then you have your own software running on the ATmega that does what it needs to in order to communicate with the Pi.
Once I get my prototypes tested there will be examples of this.
I've taken a quick look over the ROS site again, and rosserial is still there and control seems to be for more advanced systems. (Like the arm and locomotion on their PR2 robot). Personally, I would stick to using your own hardware and software interfacing to any embedded MCUs. While rosserial certainly evens the programming field across the platforms, it adds a LOT of overhead to the ATmega and things that used to work properly may no longer work as more protocol control and memory management by rosserial eats up more and more CPU time. (Rosserial on a motor controller expecting high speed quadrature encoders = many headaches)
Write a ROS node that runs on the Pi and handles writing and reading all of the appropriate data to/from the ATmega/Arduino. Then you have your own software running on the ATmega that does what it needs to in order to communicate with the Pi.
Once I get my prototypes tested there will be examples of this.