Assuming you have one of the recent Raspberry Pis (40-pin GPIO header) and you are using the first 6 pins for a PicoBorg Reverse:
There should be 24 free GPIO pins on the header which are free.
Each encoder will need 2 pins.
Maximum number of quadratures: 12.
In order for the quadrature to work it will need to respond to the input very quickly.
You may find that the Raspberry Pi cannot keep up with 12 if the motors are running fast.
This robot is using all LEGO running gear. We have maxed out the LEGO system and we want to move up to real robot components and programming. In particular, we want to run the robot at least twice as fast.
A little background. The competition is a maze solving competition. This practice maze has been intentionally poorly built to test the fault tolerance of the robot. The robot is bumping into the walls as part of a strategy to line up the robot with the maze. We do that by running the DC motors at low power and letting the motors stall when the robot hits the walls.
It is very important to us to have complete, accurate, real-time control of the wheel motors. If there is any lag then the robot twists or loses track of where it is, and then it accidentally snags on the walls and ruins the run. Do you have a solution for running these 4 motors at a high speed. Is there another board we should be looking at?
The long sticks with flags are sensors, where we use the motor encoders to sense the angle the motor has been able to travel before being stalled. We can detect the presence of the walls with the sticks.
These 4 motors can have a little lag in them. We don't care what they do in real-time. We just care about reading the encoder value once the motors have stopped moving down.
Additionally this robot has 4 ultrasonic sensors that we need to read in real-time, a gyro sensor, and infrared sensor.
Finally, we aspire to put a machine vision system on the robot to help detect the walls and hopefully replace the stick sensors.
Any and all advice is welcome. We want to start buying hardware now, but we are hesitant because this is all new to us.
From experience reading the GIPO quickly can be a bit tricky from the Raspberry Pi, the more pins you need to read the tricker it gets to be sure it saw every count.
It might be worth looking at using an Arduino to keep track of the encoder counts and report to the Raspberry Pi via serial or I2C.
There is a page here with many examples for encoders: http://playground.arduino.cc/Main/RotaryEncoders
Towards the bottom there is an example for multiple encoders that might be a good starting point.
The Raspberry Pi camera is actually rather good and should be able to 'see' walls if they are a nice contrasting colour like your demo maze.
We have a basic example on the DiddyBorg - Getting Started page, diddyFollowBall.py, which looks for a red ball in the camera image.
With the ultrasonics you can also use an Arduino, but with all of the encoder reading it may be best to offload that elsewhere.
Our UltraBorg can take care of the ultrasonic readings, it even does some basic filtering to remove some of the jitter from the ultrasonic sensors if you need it.
piborg
Fri, 07/08/2016 - 10:06
Permalink
Encoders with the Raspberry Pi
You can take a quadrature pair using the GPIO pins on the Raspberry Pi itself.
Wiring and example using C:
http://theatticlight.net/posts/Reading-a-Rotary-Encoder-from-a-Raspberry...
Wiring and example using Python:
http://guy.carpenter.id.au/gaugette/2013/01/14/rotary-encoder-library-fo...
Assuming you have one of the recent Raspberry Pis (40-pin GPIO header) and you are using the first 6 pins for a PicoBorg Reverse:
There should be 24 free GPIO pins on the header which are free.
Each encoder will need 2 pins.
Maximum number of quadratures: 12.
In order for the quadrature to work it will need to respond to the input very quickly.
You may find that the Raspberry Pi cannot keep up with 12 if the motors are running fast.
NortherNerds
Fri, 07/08/2016 - 23:41
Permalink
Hrdware suggestions?
piborg,
Thank you for the reply. It helps us understand how the parts work together.
Here is a link to some videos of our robot.
https://www.youtube.com/watch?v=vubnuoJW8nk
https://www.youtube.com/watch?v=vOREQYyP5zI
This robot is using all LEGO running gear. We have maxed out the LEGO system and we want to move up to real robot components and programming. In particular, we want to run the robot at least twice as fast.
A little background. The competition is a maze solving competition. This practice maze has been intentionally poorly built to test the fault tolerance of the robot. The robot is bumping into the walls as part of a strategy to line up the robot with the maze. We do that by running the DC motors at low power and letting the motors stall when the robot hits the walls.
It is very important to us to have complete, accurate, real-time control of the wheel motors. If there is any lag then the robot twists or loses track of where it is, and then it accidentally snags on the walls and ruins the run. Do you have a solution for running these 4 motors at a high speed. Is there another board we should be looking at?
The long sticks with flags are sensors, where we use the motor encoders to sense the angle the motor has been able to travel before being stalled. We can detect the presence of the walls with the sticks.
These 4 motors can have a little lag in them. We don't care what they do in real-time. We just care about reading the encoder value once the motors have stopped moving down.
Additionally this robot has 4 ultrasonic sensors that we need to read in real-time, a gyro sensor, and infrared sensor.
Finally, we aspire to put a machine vision system on the robot to help detect the walls and hopefully replace the stick sensors.
Any and all advice is welcome. We want to start buying hardware now, but we are hesitant because this is all new to us.
Thanks
piborg
Mon, 07/11/2016 - 11:38
Permalink
Reading inputs quickly
From experience reading the GIPO quickly can be a bit tricky from the Raspberry Pi, the more pins you need to read the tricker it gets to be sure it saw every count.
It might be worth looking at using an Arduino to keep track of the encoder counts and report to the Raspberry Pi via serial or I2C.
There is a page here with many examples for encoders: http://playground.arduino.cc/Main/RotaryEncoders
Towards the bottom there is an example for multiple encoders that might be a good starting point.
The Raspberry Pi camera is actually rather good and should be able to 'see' walls if they are a nice contrasting colour like your demo maze.
We have a basic example on the DiddyBorg - Getting Started page,
diddyFollowBall.py, which looks for a red ball in the camera image.With the ultrasonics you can also use an Arduino, but with all of the encoder reading it may be best to offload that elsewhere.
Our UltraBorg can take care of the ultrasonic readings, it even does some basic filtering to remove some of the jitter from the ultrasonic sensors if you need it.
NortherNerds
Tue, 07/12/2016 - 02:05
Permalink
Thank you!
That is incredibly useful.
Thanks