Notifications
Clear all
Topic starter
2020-04-28 8:54 pm
After looking at some tutorials for ROS it became clear that I wasn't advanced enough as a programmer to make use of it.
That's not entirely accurate. As long as the arduinos have the software for the motor controllers installed, and there's proper comms between the pi and the arduino, all you should need to do is install the nodes (ROS software packages) that you want to use
This is where I screwed up. I was trying to skip the arduino, and just use the Jetson Nano. Of course, it also means that I have to make another one of those wire-cluster boards, cuz I still want some parts inside the head, like an RTC clock for instance. Don't know why I need one, but, it seems reasonable in case I end up using the bot as an AP instead of connecting to a wifi LAN
(And, I basically have to start all over again)
The Nano or the Pi, just tells the bot to "go", and sends that signal to the rest of the "nodes". The SLAM maps out the initial path, and sends a signal to the motors, and then the lidar node keeps an eye open for obstacles
Or, if you're using remote control, you install the "turtle" node along with either "teleop-key" or "teleop-joy", and if you've got an arm, you need the "moveit" node. Well, ok, some of it has to be tweaked a bit, like how many joints an arm has, or what size is the bot, where are the wheels... etc
Yes, you can program your own nodes, and much of the training I've been taking has to do with programming the nodes, but, once I understood what was going on, I found most of it to be useless (to my goal) but, you don't have to program your own nodes cuz most nodes already exist. A lot of it is like lego's... you just put in the pieces you want
Caveat... Admittedly, this is a major simplification, but, basically accurate
2020-04-28 9:22 pm
Caveat... Admittedly, this is a major simplification, but, basically accurate
This is why I am really interested in using it. I have already had a setup with a Linux laptop, Windows 10 with Linux for Windows, a Pi, and an Arduino and have all from them communicating. It wasn't that hard. Had to use ROSSerial to talk to the Arduino, and there is an Arduino library for using ROS.
Pat Wicker (Portland, OR, USA)
2020-04-28 11:13 pm
The Nano or the Pi, just tells the bot to "go", and sends that signal to the rest of the "nodes". The SLAM maps out the initial path, and sends a signal to the motors, and then the lidar node keeps an eye open for obstacles
Without a clear example with an actual robot I still wouldn't know where to start. I assume the "node" (function to move the robot from point A to point B using the lidar) can handle obstacles on the way not just avoid them?
Functions written by others is fine if the function does what you want. If you understand the algorithm being used you can modify it to do whatever you want. When the lidar node keeps an eye open for obstacles what does it do with the obstacle? Maybe you want it to collect things (objects on the floor). When it travels down a passage way does it stick to the center? Maybe you want it to hug one side while it cleans the wall?
Now my understanding of ROS is you can write your own functions (nodes?) and they are handled by ROS but you will have to follow certain rules?
2020-04-28 11:30 pm
The Nano or the Pi, just tells the bot to "go", and sends that signal to the rest of the "nodes". The SLAM maps out the initial path, and sends a signal to the motors, and then the lidar node keeps an eye open for obstacles
Without a clear example with an actual robot I still wouldn't know where to start. I assume the "node" (function to move the robot from point A to point B using the lidar) can handle obstacles on the way not just avoid them?
Functions written by others is fine if the function does what you want. If you understand the algorithm being used you can modify it to do whatever you want. When the lidar node keeps an eye open for obstacles what does it do with the obstacle? Maybe you want it to collect things (objects on the floor). When it travels down a passage way does it stick to the center? Maybe you want it to hug one side while it cleans the wall?
Now my understanding of ROS is you can write your own functions (nodes?) and they are handled by ROS but you will have to follow certain rules?
In this case Spyder is not talking about ROS nodes but rather other parts of the robot that need to receive the "go" signal. In the case of DB1, there are two arduino nanos, one for each motor, that would receive the "go" signal though an I2C message. But it doesn't have to be that way, the PI could control the motors directly and subscribe to messages from other parts of the system and send "go" signals to the motors as needed.
Yes you can write your own ROS nodes. The rules, are no more difficult then the ones you have to follow for any reusable piece of code. It is just that ROS has a large infrastructure that you need to interface with.
The existing ROS nodes that interface to things like lidar don't take any action. Instead they are just responsible for sending out the data gathered by the lidar (this is called a publisher). Then the parts of the robot that need that data "subscribe" to it. When the ROS core, the central part of ROS, receives the lidar data it forwards it to those subscribers that requested it. Then it is up to those subscribers to decide how to react to the data.
Pat Wicker (Portland, OR, USA)
Topic starter
2020-04-28 11:51 pm
I have already had a setup with a Linux laptop, Windows 10 with Linux for Windows, a Pi, and an Arduino and have all from them communicating.
Right. One of the options is to have a desktop acting as a master, and the ROS inside the bot as a client/slave
Had to use ROSSerial to talk to the Arduino, and there is an Arduino library for using ROS.
Yea, my explanation was highly abbreviated. ROSSerial is needed to talk to the Arduino
Here's a question while I'm busy rerunning the wires... Since the plan is to use SPI for comms from the Pi (or in my case, the Jetson) to the Arduino, is there any reason to, or not to, include the i2c into the mix ? Meaning that the arduino will be using i2c for sensors and motors, but, why not include the Pi/Jetson also ?
Cuz I was just gonna connect everything together, whether it was needed or not. I figure that the Jetson can just not subscribe to any Topics that it doesn't need to care about
EDIT : I clicked "send" an hour ago on this response. But, I'm having internet problems today
2020-04-29 12:03 am
@spyder I'm really not a hardware person, but it seems to me that it would be good to have two way communications between all of the parts of the system without one part having to ask for data. That would be the advantage of Wi-Fi or BLE.
Pat Wicker (Portland, OR, USA)
2020-04-29 4:09 pm
@spyder Yeah, I've been known to look all over for the tool I know I just laid down only to discover I actually put it away where it belonged.
Pat Wicker (Portland, OR, USA)
2020-04-29 8:25 pm
@spyder I'm really not a hardware person, ...
Hardware and software are two sides of the same coin.
My limitations are due to the fact I am self taught in both hardware and software at a hobby level and have limited practice at both. I understand the concepts at the lower level (software like machine code and hardware like digital logic circuits) but struggle with higher level concepts like ROS.
My ideal robot brain would be a stand alone computer with i/o for sensors and motors. The only reason I am using an Arduino is because it provides the i/o interface via a USB port that once existed as a parallel port of some kind on the older computers (TRS-80 and C64) to your own hardware.
The Raspberry Pi does have an i/o port in the form of it GPIO.
2020-04-29 9:02 pm
However at the lower levels it is all the same. For example no matter what computer language you decide to use they all bottom out as machine code. Although even at that level Assemblers were all different. For example one used RTS (Z80 cpu) and another used RET(6502 cpu) for the RETURN command at the end of a subroutine.
2020-04-29 9:05 pm
@casey I think they were each different so we could remember which computer we were programming on at the moment. (sarcasm)
Pat Wicker (Portland, OR, USA)
Topic starter
2020-04-29 9:39 pm
Remote control in a real robot would be limited to sending the robot commands not in actually controlling everything it does. The video camera would be eyes for the robot not as a remote camera for a human viewer to do the controlling of the robot.
"Remote Control" is so 20th century
I prefer the term "Telepresence" 😉