I’m trying to use a Raspberry pi to receive GPS coordinates from a Pi HAT and to drive several motor controllers to move a robot around controlled with GPIO pins. I’m able to run the sample problems fine. When I try to combine changes GPIO outputs into the code it becomes much less stable an eventually crashes when reading GPS data.
It is also output this message:
listening for UBX Messages.
A stream read returned 0 bytes, expected 4 bytes
It seems from reviewing the tutorial (https://learn.sparkfun.com/tutorials/sp … rview-phat) that most of the pins are pass through. Do you have any tips? It seems like I’m not getting valid data in my combined code with the motor controllers
Handling GPS data and motor control in separate threads can help manage timing issues. Use Python’s threading module to create separate threads for reading GPS data and controlling motors. This can help prevent one process from blocking the other.
I’ve tried completely separate python scripts and the interference still happens which is leading to my Gpio question. Would that be a similar comparison to threads?
I think that Threading may be a red herring here, or at least a premature road to go down without understanding more about the issue. Let’s look at the system as a whole first, and then work out what parts of it could be in conflict.
Jefswat, can you give us more information about your setup? Imagine you were trying to troubleshoot this problem for someone on a forum; what information would you need in order to help them solve their problem? I often find this is a good way to troubleshoot my own work, helps to develop a fully fleshed out system description.
Here are some base questions that need to be answered, but feel free to go beyond this. Description is king in the engineering world:
What are all of the devices in the system? This description should be precise enough that every device can be researched, bonus points if you include links to the datasheet for each device.
How are these devices connected? Text descriptions are good, block diagrams are good, pin and interface mappings are better.
What code is being run? I’ve found an easy method to share this is to put everything in a git repository, then share the link. If there is a lot of code, or it is highly complex, creating a [minimal reproduceable example is extremely helpful.[/u] 4) What do you expect to happen when you run the code, and what actually happens? You shared some kind of error output, but it isn’t clear where that message comes from, and if there is more. Can you elaborate on “combine changes GPIO outputs into the code it becomes much less stable an eventually crashes”? It can be a lot of work putting all of these descriptions together, but in doing so you’ll understand much more about how your own system is running; sometimes the issue becomes quite obvious just from creating a precise description of it.](How to create a Minimal, Reproducible Example - Help Center - Stack Overflow)