0

Background: I'm working on a project with a self-driving machine with a tank-like control, somehting like:

  • forward()
  • left()
  • right()
  • stop()

The code is running on a raspberry pi. The GPIO outputs are inside my class Machine. Currently the development process is very simple, we're programming, put on raspberry, test it on the real machine. This process slow down the development very much. Are there common design patterns to implement a Simulation. The goal have to be to keep the model untouched, to use same code for real, as for simulation.

tbzk
  • 11
  • 2
  • 1
    It sounds like you need a way to test your code then? – Greg Burghardt Feb 04 '19 at 18:35
  • Well, you need some sort of output similar to the actual device, including some way of taking player input. I guess your constraints are the same OS used in the Raspberry Pi. Wonder if you can download the same version of OS used on the Raspberry PI, and then use something like Virtual Box to create a virtual machine to simulate the hardware, and create a build script to compile and deploy to the VM. – Greg Burghardt Feb 04 '19 at 18:42

2 Answers2

1

Fortunately you can run Linux on a Raspberry PI. That means you can install the same flavor of Linux as a virtual machine on your own computer. After that create a build script that packages the application up, along with any dependencies, and then deploys it to the Linux VM running on your computer. Most virtual machine managers allow you to specify some basic hardware requirements, like the number of CPUs and RAM, along with disk space.

This would give you some beefy hardware to develop and test with (much more than a Raspberry PI) which should speed up development, but will present performance and integration issues with the actual device.

From there you'll want to profile the application somehow so you can monitor how much RAM and CPU it uses so you can catch some of the performance bottlenecks early.

Really, nothing beats testing it on the real device. You might have bug free code that runs like garbage on minimal hardware forcing you to re-engineer major parts of your code base, which will cause a slowdown in the project as well. So it's a balancing act.

Greg Burghardt
  • 34,276
  • 8
  • 63
  • 114
0

In addition to Greg's answer there are some other things that you can do with your code once you get it running on the VM.

From what I understand the Pi's GPIO are memory mapped devices, thus you can write an out of band process that monitors the Output bits and reports their values so you can track how the hardware is being driven. (Note that you need to verify that the responses you see match the actual hardware - EG set up some simple test cases)

Once you can monitor the outputs then you can feed them into a hardware simulation that estimates the physical location of the vehicle. This can be as simple or complicated as you want. The aim is not to be perfect but to give feedback to the user that when you run the forward() command for 10 seconds, the vehicle moves 10 times further than if you ran it for 1 second. You also accumulate distance with simple time based integrations to change the vehicles location.

The final step is then to add on to your simulation and feed simulated sensor data back into GPIO inputs based on where the vehicle is in the simulated world, and show how your actual vehicle code responds. EG when a sensor detects a simulated cliff in front of the vehicle, your actual vehicle code should be seen to stop the forward motion.

The goal is not to produce a perfect real world simulation of you vehicle, but to act as a tool to help you verify that you consume inputs and generate outputs in a manner that seem reasonable - IE showing that you have dotted your I's and crossed your T's in your code. Thus you should aim for the simplest and dumbest simulation that achieves that goal and avoid the temptation to make your hardware simulation perfect.

Peter M
  • 2,029
  • 2
  • 17
  • 22