This repository provides source code for beaglebones for the OpenDLV.io software ecosystem.
No dependencies! You just need a C++14-compliant compiler to compile this project as it ships the following dependencies as part of the source distribution:
This microservice is created automatically on changes to this repository via Docker's public registry for:
To run this microservice using our pre-built Docker multi-arch images to connect to an OXTS GPS/INSS unit broadcasting data to 195.0.0.33:3000 and to publish the messages according to OpenDLV Standard Message Set into session 111 in Google Protobuf format, simply start it as follows:
docker run --rm --net=host chalmersrevere/opendlv.io-multi:proxy-beaglebone-v0.0.1 beaglebone --cid=111 --verbose
To build this software, you need cmake, C++14 or newer, and make. Having these
preconditions, just run cmake and make as follows:
mkdir build && cd build
cmake -D CMAKE_BUILD_TYPE=Release ..
make && make test && make install
Make sure you have the latest docker version. 1.17
AMD64: Run
docker build -t chalmersrevere/opendlv.io-multi:proxy-beaglebone-v0.0.1 -f Dockerfile.amd64 .
ARMHF: Run
docker build -t chalmersrevere/opendlv.io-multi-armhf:proxy-beaglebone-v0.0.1 -f Dockerfile.armhf .
Make sure you have the latest docker-compose verison.
AMD64: Run
cd usecase
docker-compose up
ARMHF: Run
cd usecase
docker-compose -f beaglebone.yml up
- This project is released under the terms of the GNU GPLv3 License
This service is responsible for generating the appropriate PWM signal for the brake actuators given a GroundDecelerationRequest.
- GroundDecelerationRequest (From congition-track or cognition-acceleration)
Outgoing
- PulseWidthModulationRequest
The duty cycle of the PWM signal is calculated as a linear function of the deceleration request.
- Code needs refactoring
In our car, we have three main components that we can control to make the car move: The linear actuator (steering), the brakes (braking) and the inverters (motion).
The logic-action-x services are responsible for calculating an appropriate control signal for their respective components given some reference signal(s) sent from the main cognition service (cognition-acceleration or cognition-track).
There are two different OD4Sessions in each service: One that is responsible for receiving messages from cognition-services, and one that is responsible for sending messages to low-level services.
To improve: We believe that the solution to have three independent microservices responsible for generating the control signals for each of the control components (steering, inverters, brakes) is restrictive. As it is now, it's hard to implement a control scheme where different control signals are dependent by design.
To improve: The naming of the OD4Session which communicates to the low-level stuff (StateMachine, aka. BeagleBone) is very inconsistent between the logic-action services. Basically, od4_proxy (steering), od4Brakes (braking) and od4StateMachine (motion) all live on the same conference with defaullt CID=219.