1
$\begingroup$

I am trying to understand how AWS RoboMaker and WorldForge work, and am having trouble "seeing the forest through the trees," and might need someone to "explain it to me like I'm 5" (ELIF).

Do you:

  • Write your robot's firmware (in any language/library/RTOS you choose) and upload it to AWS and run it through their simulations/tests/workbenches? or...
  • Write your robot's firmware in Python (which seems to be the only language they currently support, at least in the examples I can find), use their Python libraries/modules for interacting with their WorldForge simulations, and upload your Python code to AWS and run it through their simulations/tests/workbenches; or...
  • Something else completely different?

Thanks for any clear + succinct (good step-by-step examples would be amazing!) steering here!

Improve this question
$\endgroup$

1 Answer 1

Reset to default
1
$\begingroup$

If you take a look at their Getting started > Concepts section, they mention

A typical simulation might use Robot Operating System (ROS) with one container simulating the environment in Gazebo, and a second container simulating the robot.

As I discuss in my answer to your other question, your robot needs some way to interact with the virtual environment. By the way it's described above, Amazon is assuming you're going to have some network I/O that will bridge your robot to the simulated environment. The simulated environment would be what hosts your virtual robot, with all the virtual sensors and encoders, etc. The virtual environment would all be put on one docker container.

The robot (as described by Amazon in the quote above) would run on another docker container. Your robot runs on whatever software you choose to write, Python, C++, etc., and it communicates over that network I/O to the simulator, which will generate synthetic feedback based on whatever your virtual sensors are programmed to do.

Improve this answer
$\endgroup$
5
  • $\begingroup$ Thanks @Chuck (+1) I will likely have more followup questions, but the first was is this: is AWS RoboMaker expects your robot to be able to run on a docker container, doesn't that preclude any real production robotics that would be running on ARM hardware an using real-time OSes like RIOT-OS and the likes? I believe docker is only linux and x86/64 architecture, no? Thanks again so much! $\endgroup$
    – hotmeatballsoup
    Sep 6, 2022 at 18:03
  • 1
    $\begingroup$ @hotmeatballsoup - Yup, pretty much, unless you've got a hardware emulator as I suggest in the other answer. Otherwise you're going to have to either structure your software such that it's not hardware-dependent or keep a parallel code base that has replaced the hardware dependencies with your simulated hardware interface. $\endgroup$
    – Chuck ♦
    Sep 6, 2022 at 18:06
  • $\begingroup$ Thanks again (+1), so it sounds like AWS RoboMaker cannot be used for building anything that doesn't run on x86/64 architectures (like ARM), and it cannot be used for anything that needs to run on an RTOS. But say I am writing a robot with firmware that will run on an x86 chip, and is OK with using some flavor of Linux (alpine, whatever). Maybe I'd write this firmware in C, C++ or even Python... $\endgroup$
    – hotmeatballsoup
    Sep 7, 2022 at 1:58
  • $\begingroup$ If my application fits this description, then doesn't AWS RoboMaker do what I asked about in my other question? Meaning, it sounds like it will allow me to receive my inputs from the network I/O bridge, that were generated by the simulated environment "running" my virtual robot, then respond to those inputs, and then send the output commands back over the network I/O bridge back to the simulated environment, no? $\endgroup$
    – hotmeatballsoup
    Sep 7, 2022 at 2:00
  • $\begingroup$ @hotmeatballsoup - If my application fits this description, then doesn't AWS RoboMaker do what I asked about in my other question? Yes, that's the point of it haha. The issue it sounds like you may have though is splitting out the hardware dependencies from your project. Instead of sending a PWM signal to Pin9, which won't exist in a docker container (without a hardware emulator), your code should send the PWM signal to some kind of an abstracted motor driver, you can have motor driver different implementations, one that forwards to Pin9, one that forwards to ROS or another network protocol. $\endgroup$
    – Chuck ♦
    Sep 7, 2022 at 2:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.