Üapp: picar-s v2.0, picar-4wd forks and basic organization

This task will create forks of the picar controller source repositories within https://github.com/uberspark in preparation to build corresponding uobject collections. The following are proposed sub-tasks:

  1. fork https://github.com/sunfounder/SunFounder_PiCar-S as https://github.com/uberspark/uapp-SunFounder_PiCar-S

  2. fork https://github.com/sunfounder/picar-4wd as

  3. create branches uobjcoll within each of the forked repositories. So the master branch will be used to grab upstream changes, and we will use the uobjcoll branch to develop the CPS controller application uobjcoll.

  4. build and be able to run the apps on both forks off the master branch; testing on the actual hardware will be another task. NB: build/installation is driven by a script within the repository

  5. isolate the line-following feature modules and convert them to C code with python bindings on both the forks in the uobjcoll branch. This C code will also likely include the Python SMBUS C code (https://github.com/pimoroni/py-smbus/blob/master/library/smbusmodule.c) as part of it. This sub-task will be introduced as a pull-requests (PRs) so we can document and track refactoring changes to the original code-base.

  6. build and be able to run the apps on both forks off the uobjcoll branch with the new C code substitution; testing on actual hardware will be another task

Just a note. When I called C from python, I used ctypes. There are probably multiple ways to do this, just wanted to share my experience.

Thanks for the insights @Cap! Am sure your experience could come in handy as @antonhristozov tackles this task.

I did 1 - 3, but there is nothing to do for 4, since there is are no C files or a Makefile. There is only Python (*.py) files in both repositories.

Yeah, perhaps we can skip 4 in this case. Thanks @antonhristozov

We have line_follower.py and track_line.py in each repository respectively, both located in the example folder. I will look at the right approach to convert this to C before doing it.

Great! Sounds good!

I have set the branch permissions on the task repos to allow merges via PRs. So let us add 5 and 6 using PRs as the workflow. This will also help us document and keep track of refactoring changes to the original code base.

Thanks @antonhristozov!

Also, I came across this utility which supposedly converts from python to C/executable code:

We could try to apply this on the python code base to see if we are able to get some automation as we work on converting to C.


Thanks, I will take a look and see how useful it is.

According to the instructions the installation of the code and development is done only on the raspberry pi itself. There is a script install_dependencies, which is meant to be run on the Pi and install everything that is needed for the code to run. It pulls stuff from git through the Pi’s connection to the Internet. I have a raspberry Pi 3B+ that can be used for this.

I am guessing you are referring to the picar forks? If so, it would be good to run this script and see if it works on the master branch of each of the fork. This would correspond to subtask-4 in the OP I am guessing.

Once we get the build/install working on the master branch, we can move to subtask-5 which is to convert the line-following Python modules into C. In conjunction with subtask-5 we might have to tweak the installation script and/or add a Makefile for subtask-6 eventually.


Yes, it is about the forks I created, but they are the same as the original repos. The development has to happen on the Pi, so that we don’t spend time on doing cross compilation efforts. Let me see how it works on the Pi platform.

Do the dependency installation scripts download and build software packages?

Yes they do download dependencies like pmc-bus module, etc. I have not run it yet, but looking at the script and the documentation so far.

Ok sounds good. Please post your findings on what the script does at a high-level and that may help us figure out the best path moving forward.

The next generation uberSpark tool-chain has support for both native and containerized bridges (via docker) for compiling, assembly and linking, but the verification bridge is currently only supported through containers.

So in principle using the next-gen toolchain should be relatively straightforward on the pi3 when we are building uobjects. However, memory/performance might be an issue especially with containerization (using docker) and verification.

Worst case, we might need to build an ARM/Raspbian docker development environment for the picar repository that we can run using emulation on x86, perhaps borrowing from something like this: https://www.stereolabs.com/docs/docker/building-arm-container-on-x86/

I also found this available Raspbian/Jessie (currently supported by uberXMHF) docker container image for amd64: https://hub.docker.com/r/raspbian/jessie

This might be one way to go if we need to adopt the cross-compilation route…

The information about what the script does can be found in Appendix 1 of
Picar-S User Manual, located in the doc folder of the repository.
This is what the script install_dependencies does:

  1. Update the apt list.
    sudo apt-get update
  2. Install python-smbus.
    sudo apt-get install python-smbus -y
  3. Install the PiCar module.
    cd ~
    git clone --recursive https://github.com/sunfounder/SunFounder_PiCar.git
    cd SunFounder_PiCar
    python3 setup.py install
  4. Enable I2C.
    Edit the file /boot/config.txt
    sudo nano /boot/config.txt
    The “#” in front of each line is to comment the following contents which does not take
    effect in a sketch. The I2C configuration part is commented by default too. Add the
    following code at the end of the file, or delete the pound mark “#” at the beginning of
    related line; either way will do.
  5. Reboot.
    sudo reboot

Here is the output from running getting the repository and running the script on a raspberry Pi:
picar_install_log.txt (14.3 KB)

Thanks @antonhristozov! I take it that the build/installation went off successfully on the pi3 then. I have revised the OP subtask-4 with the details.

Just to clarify, in step-3 above, what does the python3 setup.py install do? Is this something similar to make install for Python?

Perhaps we can move on with subtask-5 in the OP on the pi3 and see what changes we may need to make to the existing flow so we can convert the existing line following module into C, compile and install it with the rest of the modules