The site is read-only. Please transition to use Robotics Stack Exchange
| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
 | 1 | initial version |
Another option: "A" computer ssh's to "R" and does their editing and running there. Drawback is that the "R" SBC is slow and it won't allow user of "A" to use their favorite text editor.
you have quite a nr of constraints, but two approaches that come to mind:
The first would be a low-fi solution, almost trivial to setup: SSH clients are available on all OS, and SCP clients as well. Find one which allows to continuously synchronise a directory on the students laptop/pc/whatever with one on the robot. Open a shell session over SSH, navigate to synchronised directory, execute script.
The second would be fancier, and would probably appeal to non-command-line users. I haven't done this myself, but there are web based IDEs, even ones that allow you to execute code remotely as well. There are two main variants:
An example of option 1 would be os.mbed.com (note: it's an example of the concept, I'm not suggesting you use mbed os or their online environment). Perhaps the team city approach mentioned by @ChuiV is an example of this as well. I believe the main work here will be setting up your robot to make it a suitable target device for deployment.
The second option is essentially similar to the first one, but you'd run one of the cloud-based web IDEs in their self-hosted configuration. As 'everything' is already running on the robot, it would already be the target device. I imagine there will be less setup work, but I'm not sure.
A variant of the second option could be where a more powerful machine (but still local) hosts the web-based IDE and your robot is still setup as a target device. That could work around limited hw/processing capabilities of your robot.
Note that none of the web-based approaches will allow students to use "their favourite text editor". But tbh I doubt that is really something you should constrain yourself by. Unless that text editor happens to be an actual IDE, things like code-completion and linting are not going to be automatically available. Those are valuable features, so I wouldn't want to develop without them, but these are students, so perhaps your goals are different.
Finally: the SSH+SCP approach should take 30 mins to setup, max. The web-based stuff is much nicer but will take some time to figure out and setup.
| | 2 | No.2 Revision |
Another option: "A" computer ssh's to "R" and does their editing and running there. Drawback is that the "R" SBC is slow and it won't allow user of "A" to use their favorite text editor.
you have quite a nr of constraints, but two approaches that come to mind:
The first would be a low-fi solution, almost trivial to setup: SSH clients are available on all OS, and SCP clients as well. Find one which allows to continuously synchronise a directory on the students laptop/pc/whatever with one on the robot. Open a shell session over SSH, navigate to synchronised directory, execute script.
The second would be fancier, and would probably appeal to non-command-line users. I haven't done this myself, but there are web based IDEs, even ones that allow you to execute code remotely as well. There are two main variants:
An example of option 1 would be os.mbed.com (note: it's an example of the concept, I'm not suggesting you use mbed os or their online environment). Perhaps the team city approach mentioned by @ChuiV is an example of this as well. I believe the main work here will be setting up your robot to make it a suitable target device for deployment.
The second option is essentially similar to the first one, but you'd run one of the cloud-based web IDEs in their self-hosted configuration. As 'everything' is already running on the robot, it would already be the target device. I imagine there will be less setup work, but I'm not sure.
A variant of the second option could be where a more powerful machine (but still local) hosts the web-based IDE and your robot is still setup as a target device. That could work around limited hw/processing capabilities of your robot.
Note that none of the web-based approaches will allow students to use "their favourite text editor". But tbh I doubt that is really something you should constrain yourself by. Unless that text editor happens to be an actual IDE, things like code-completion and linting are not going to be automatically available. Those are valuable features, so I wouldn't want to develop without them, but these are students, so perhaps your goals are different.
Finally: the SSH+SCP approach should take 30 mins to setup, max. The web-based stuff is much nicer but will take some time to figure out and setup.
Edit: if you don't have a particular need to use an actual rospy installation, then perhaps something like rosbridge_suite in combination with gramaziokohler/roslibpy might also work. Requires no ROS installation and can be run on any OS that supports Python. If the laptop/PC can communicate with the robot over a network, so can roslibpy.
It's going to be different to rospy though: it's not a drop-in replacement.
| | 3 | No.3 Revision |
Another option: "A" computer ssh's to "R" and does their editing and running there. Drawback is that the "R" SBC is slow and it won't allow user of "A" to use their favorite text editor.
you have quite a nr of constraints, but two approaches that come to mind:
The first would be a low-fi solution, almost trivial to setup: SSH clients are available on all OS, and SCP clients as well. Find one which allows to continuously synchronise a directory on the students laptop/pc/whatever with one on the robot. Open a shell session over SSH, navigate to synchronised directory, execute script.
The second would be fancier, and would probably appeal to non-command-line users. I haven't done this myself, but there are web based IDEs, even ones that allow you to execute code remotely as well. There are two main variants:
An example of option 1 would be os.mbed.com (note: it's an example of the concept, I'm not suggesting you use mbed os or their online environment). Perhaps the team city approach mentioned by @ChuiV is an example of this as well. I believe the main work here will be setting up your robot to make it a suitable target device for deployment.
The second option is essentially similar to the first one, but you'd run one of the cloud-based web IDEs in their self-hosted configuration. As 'everything' is already running on the robot, it would already be the target device. I imagine there will be less setup work, but I'm not sure.
A variant of the second option could be where a more powerful machine (but still local) hosts the web-based IDE and your robot is still setup as a target device. That could work around limited hw/processing capabilities of your robot.
Note that none of the web-based approaches will allow students to use "their favourite text editor". But tbh I doubt that is really something you should constrain yourself by. Unless that text editor happens to be an actual IDE, things like code-completion and linting are not going to be automatically available. Those are valuable features, so I wouldn't want to develop without them, but these are students, so perhaps your goals are different.
Finally: the SSH+SCP approach should take 30 mins to setup, max. The web-based stuff is much nicer but will take some time to figure out and setup.
Edit: if you don't have a particular need to use an actual rospy installation, then perhaps something like rosbridge_suite in combination with gramaziokohler/roslibpy might also work. Requires no ROS installation and can be run on any OS that supports Python. If the laptop/PC can communicate with the robot over a network, so can roslibpy.
It's going to be different to rospy though: it's not a drop-in replacement.
| | 4 | No.4 Revision |
Another option: "A" computer ssh's to "R" and does their editing and running there. Drawback is that the "R" SBC is slow and it won't allow user of "A" to use their favorite text editor.
you have quite a nr of constraints, but two approaches that come to mind:
The first would be a low-fi solution, almost trivial to setup: SSH clients are available on all OS, and SCP clients as well. Find one an SCP client which allows to continuously synchronise a directory on the students laptop/pc/whatever with one on the robot. robot (winscp for Windows supports this). Open a shell session over SSH, navigate to synchronised directory, execute script.
The second would be fancier, and would probably appeal to non-command-line users. I haven't done this myself, but there are web based IDEs, even ones that allow you to execute code remotely as well. There are two main variants:
An example of option 1 would be os.mbed.com (note: it's an example of the concept, I'm not suggesting you use mbed os or their online environment). Perhaps the team city approach mentioned by @ChuiV is an example of this as well. I believe the main work here will be setting up your robot to make it a suitable target device for deployment.
The second option is essentially similar to the first one, but you'd run one of the cloud-based web IDEs in their self-hosted configuration. As 'everything' is already running on the robot, it would already be the target device. I imagine there will be less setup work, but I'm not sure.
A variant of the second option could be where a more powerful machine (but still local) hosts the web-based IDE and your robot is still setup as a target device. That could work around limited hw/processing capabilities of your robot.
Note that none of the web-based approaches will allow students to use "their favourite text editor". But tbh I doubt that is really something you should constrain yourself by. Unless that text editor happens to be an actual IDE, things like code-completion and linting are not going to be automatically available. Those are valuable features, so I wouldn't want to develop without them, but these are students, so perhaps your goals are different.
Finally: the SSH+SCP approach should take 30 mins to setup, max. The web-based stuff is much nicer but will take some time to figure out and setup.
Edit: if you don't have a particular need to use an actual rospy installation, then perhaps something like rosbridge_suite in combination with gramaziokohler/roslibpy might also work. Requires no ROS installation and can be run on any OS that supports Python. If the laptop/PC can communicate with the robot over a network, so can roslibpy.
It's going to be different to rospy though: it's not a drop-in replacement.
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
