Closed Sarxell closed 2 years ago
Hi @vitoruapt and @miguelriemoliveira ,
So, me and @manuelgitgomes thought that it was very weird for the arduino only giving positive values so we decided to change the code to a more precise approach using two interrupts. This worked! You can se a video when we drive 1.80m (the wheels' perimeter) and the pulses the encoder gives us:
Here is the car moving :
https://user-images.githubusercontent.com/92535336/170281740-b62c4b45-823a-4222-829d-8741e6e37692.mp4 (Beware, it has sound!)
We also send these values to the atlascar2 cmd_vel topic which the ackermann_controller uses to calculate the odometry so we can see the car moving in the simulation: With the measuring tape we measured 1.50m (rough) and the simulation moved 1.63 , this needs more tests because the gazebo has simulated forces and inertias! With rviz and with longer paths we will be able to see more realistic results! We hope to do it next week when the eletric panel is completed
Fine! Double interrupt was after all a positive approach ;-) @Sarxell A doubt remains: what is the maximal speed of the car for the Arduino not to skip pulses? Is it possible to calculate that?
Hi!
It "is" possible!
Checking the atlascar2's specifications it says the max speed of the car is 130km/h
130 km/h -> 36.1 m/s We can check the number of turns the wheel gives using its perimeter. With a radius of 0.285 m -> 2pir = 1.79 m
36.1/1.79 = 20.16 turns per second
Since the encoder as 1000 ppr -> 1000 * 20.16 = 20160 pulses per second
BUT, checking the code we have two interrupts both on change! which means x4 that value for interrupts: 80 640 interrupts/second ... So we need a little more than 80 kHz if I'm thinking right but I can be mistaken.
This seems small since the Arduino says that it provides 16/20 MHz ... But it doesn't. If we are not using it sure but each instruction decreases this value by a lot. A realistic value by the forums is 275 kHz if the Arduino only interrupts or does a small program ...So in reality I don't know since it depends on the code... we could test this on the road but without the electric panel we can only drive inside DEM at low speeds...
OK. It seems reasonable, however I do not understand why you have interrupts on both the rising and falling edges of the pulse. Wouldn't it be enough to have only in one of them? Concerning maximal interrupt rates in Arduino, you can check some more tentative realistic calculations at https://forum.arduino.cc/t/max-interrupts-second/357256/8. With the increase of speed of the car, less time may be left available in the Arduino to dispatch the message to the CAN bus. So, perhaps, that's one more reason to include the Arduino time stamp in the CAN message along with the encoder value.
Solved
Hi @vitoruapt and @miguelriemoliveira ,
This is a mystery! Me and @manuelgitgomes are using the Atlascar2 with the arduino and counting the pulses but, when we move back and forward, the counter only counts one direction , positive or negative, the problem is that the code already worked this morning! We are very confused! The pulses of the oscilloscope before entering the arduino are correct has it can be seen here:
https://user-images.githubusercontent.com/92535336/170055078-49367a04-7003-49ca-b30a-47139ae15f88.mp4
Here are the arduino pulses ( the X and Y axis can't be changed, sorry)![Screenshot from 2022-05-24 15-07-43](https://user-images.githubusercontent.com/92535336/170056082-6a9704ee-574f-45ec-b900-7f87fcc4bbd9.png)
Forward values:
Back values:![Screenshot from 2022-05-24 15-08-05](https://user-images.githubusercontent.com/92535336/170056054-7b00bc61-e4c0-402e-abd2-3058e481a673.png)
Independently of the movement, the orange value is always high when the blue is rising, making it indistinguishable when going forward or backward .