View: 404|Reply: 2

Adeept codebase - Where is it going?

[Copy link]

4

Threads

13

Posts

44

Credits

Newbie

Rank: 1

Credits
44
Post time 2023-12-14 01:35:26 | Show all posts |Read mode
TLDR; It's not going anywhere unless I start over.

The long story:
It's a confused mess of threads and globals.
There are multiple places where direct control is taken over hardware (ie. servo pwm) with different settings for each in each location.

Magic numbers everywhere.  Why are servos numbers instead of named objects?  Python has these beautiful dictionaries for organizing stuff by name.  We need that.

Why do I have to go into code to change servo direction and limit movement?

Configuration is difficult because threads start in an uncontrolled way, sometimes as globals.

There is a weak attempt to have configuration using a bespoke file format.  What is wrong with using json or some other well known format?  Given the correct structure objects can serialize themselves.

Instead of a single repository/codebase which is adapted to each vehicle, there is a repository for every vehicle which is horrible to maintain.

There is a half hearted attempt to have objects and structure but it just falls back to lazy globals most of the time.

There are so very many threads.  Each one with overlapping responsibilities of the others.  What is going on?

The webpage is not open source and the GUI is not functional.  The webpage is preferred so it can be controlled from phone or tablet.

There result is that adding functionality is near impossible.
Sudo for GPIO sucks and forces everything to be sudo. Maintaining git with sudo is a drag.  We can do better.

What to do?
Rework the existing codebase? - No.  Tried it. Its a tangled mess.
Start again? Painful but maybe not too bad to get basic functionality.  Mostly based on the existing solution but with better architecture.
PX4 - Yes and no.  Excellent message passing control between processes.  Just a different bunch of maintenance problems.
ROS - Obsolete
ROS2 - Steep learning curve and horrible version dependencies depending on OS versions.  No.

At this point start again seems to be the best option.  I just don't like it.



Reply

Use magic Report

4

Threads

13

Posts

44

Credits

Newbie

Rank: 1

Credits
44
 Author| Post time 2023-12-14 05:03:30 | Show all posts
Solve the awkward sudo gpio problem by using pigpio.  This runs a deamon that can accept a remote connection.  Development can be local or remote.  Just connect to it and request the gpio, i2c, spi, pwm to do what needs to be done.  This neatly removes all the sudo from the project.

Reply

Use magic Report

4

Threads

13

Posts

44

Credits

Newbie

Rank: 1

Credits
44
 Author| Post time 2023-12-14 13:54:42 | Show all posts
Yes.  pigpio remote access is the way.
Using the examples I have gpio, servo and motor control from a remote pc.
There is an example for the ultrasound distance measurement.

No example for the WS281x LED driver
rpi_ws281x is a userspace library so that is less of a problem.

The OLED display is a bit more of a mystery.  This is not high priority.
Reply

Use magic Report

You have to log in before you can reply Login | Sign Up

Points Rules