PID speed controller

[dclause]

Hi ! I wondered if it would be interesting to setup a speed control within watney robot using this kind of motors : https://www.dfrobot.com/product-1457.html?gclid=Cj0KCQiAsbrxBRDpARIsAAnnz_PhEx8-o3IdeGfHtnVxXILQznXau51J_REz-_1r_2tdGmzQhWN6Fx0aAkb5EALw_wcB

The speed control could be done via the software or I wondered if this kind of card would fit in the robot if removing L298N (would not be necessary anymore in that case) : http://www.dagurobot.com/Robot_Controller/Rover5_tank_motor_driver_board

Could you eventually advice me on this ? I am wondering if driving straight while using FPV is easy or not without that kind of pid control.

[nikivanov]

Hi!

Watney may not drive in the straight line if one of the sides spins faster than the other. There is rudimentary trim control in the config, which allows you to slow down one of the sides to compensate for it. This is a constant offset factor, so it won't work universally for all surfaces. What I usually do when driving a Watney is press and hold forward and adjust it manually by tapping left / right to compensate for it veering off course.

The motors you posted in the first link will give you feedback of how quickly they are turning. If you read all 4 motors' feedback, you can slow down one side if the other one is spinning slower in real time, which should give you better straight line driving. It still won't handle cases when one side is stuck with wheels spinning freely.

The board you posted should do all of this for you, though I've never tried using one like that. You can still use L298N, read the encoder data using the raspberry pi and adjust each side's speed accordingly. Note that since the motors are connected in parallel on each side, you can't control them individually, which would be optimal - you'd read all 4 encoders, determine the slowest motor, and adjust the other 3 to that speed.

Hope that helps!

[dclause]

That helps a lot indeed ! Thanks a lot for your answer, and I am sorry for the lacks of my english in the rather long answer coming next.

I hope to build a robot that would be nice looking (ie not with no cables out everywhere), self battery charging, with a camera feedback to FPV-drive it, easy to maneouver, and small enough to navigate into ventilation duct (yep... that's a bit weird as a requirement !)

• I have built a custom bot over a dagu rover5 plateform that partially fits the need (currently running perfectly fine but running on arduino with a radio shield, would need to be turned to raspberry for wifi). Problem : the plateform is too big in essence.
• I have a custom bot inside a ZeroBot Pro chassis that works fine but is not able to go straight and the plateform is too small for including the wireless charger and more important : the motors' encoders and driver.

Hence, I think the shape of your platform has a perfect size. Plus I must say, the pieces prints perfectly, the "circles" under the pieces to help it sticking is a little detail that shows how well design they are. Well... kudos to you sir !

I have multiple hardware solutions that has been tested separately. I just can't get them fit all into one printable plateform. Each solution would need small adjustments, mainly in the places for the M3 screws. (for instance if replacing the L298N with the motor board I suggested in the bottom.stl). The biggest change would be eventually if you had a mix between v1.3 and v2.0 cover.stl file : a cover that would fit the raspberry zero AND the audio bonnet in the same time.

Main reason for it : the raspberry A+ consumes 2.5x as much as the raspberry Zero while I don't require the extra computational power. And I would like to use that room for extra circuits :

• power switch (I could not find one in the current design)
• headlights (hence 2 resistors and a BC337)
• battery remaining charge reader (hence an ADC such as MCP3008 or ADC1115 which could also work as an encoder counter).

Your plateform is the closest I have found currently to my requirements but some details are different to your solution. Maybe this question is too much to ask, but do you have original 3D files for share too so i could change it easily to my requirements ?

I had write a very long solution describing multiple solutions :

• battery shield on the bottom plug directly to a type be wireless charger receiver (that would make the whole 'audio bonnet' useless in term of space.
• two L298N vs 4-motor driver board to benefit from the 4 wheel encoders
• software PID vs hardware PID but after all, I think this was boring thoughts which all came down to the same : to test it, I always need some STL changes that I can't do.

In the software area, I already have it all (in nodeJS though) : the camera handling, the headlights, the encoders etc... the whole point is to drive the robot via FPV-google using a PC joystick so straight lines needs to be straight, otherwise the driving in the ducts is a nightmare.

I am rather close to my need : just being able to fit the hardware into something I can 3D print.

[nikivanov]

Hi!

1. There is a power switch - it's the switch on the power board, accessible from the side on the audio bonnet. It cuts off all the power immediately, so it's not like a power button that you can handle in software.
2. If you want bidirectional audio, you have to use RPI 3A+. The reason I switched from Zero W is because it didn't have enough compute to encode / decode audio in addition to all the other stuff. WiFi is also a lot better on 3A+. On the other hand, if audio is not a requirement and WiFi strength isn't a concern, it should be easy enough to retrofit Watney to use Zero W again.
3. It's not too much to ask for original 3D files - in fact, they are already there! Under STLs, you can find watney.iges - you should be able to import it in a CAD software of your choice and mess around with it there.
4. Since you want to read battery voltage and have a dedicated encoder counter, you might as well add an Arduino Nano and slave it to the RPi. This would be a very cost effective solution. You can also have hardware PWM for motors and the camera servo that way.
5. There are many ways to accomplish what you're looking for with regards to going in straight lines. If your goal is to minimize changes, I'd do the following:

• Couple each side of motors with a toothed idler and a belt, like GT2. That should synchronize the rotational speed of each pair of motors. The current design should allow for this without modification of existing parts.
• Read one of the motor's encoders from each side and adjust each side's speed using PID or some other algo. You can probably keep all of the logic for that on Arduino and RPi will just issue high-level commands to it, like "forward 100%".

Please note that if you decide to do this, you'll need to open source your project as well.

[dclause]

Thanks a lot for all those comments, you are awesome :)

1. I did not noticed ! At first sight I though the bonnet opening would be in front of the USB-type C port. I have not received the proper shield yet though, maybe that is why. I will double check as soon as received.
2. I don't need the audio indeed. But maybe that still would be more future-proof to go on with the A+. Any idea how long would the battery last with this ? (recommanded one at 3000mAh)
3. Many thanks. You can tell 3D is not my strength ! I did not know about this iges extension file. I need to learn more on this area :)
4. I though about the arduino nano solution indeed. To be honest, I thought that this would be an overkill solution. I guess I can generate the PWM from the raspberry itself using pigpio library. That may be not as effective as real hardware PWM, I have to test if running four motors and the servo with this technic, but that seems enough at first sight.
5. I like the belt idea :) that could be inner or outer if the wheels become a tank.

I will think more about it when I receive the required parts i will let you know. Regarding all changes (plus the fact everything is written in nodeJS), I guess the only remaining will be the 3D parts. I hope to come up with interesting feedbacks soon.

Thanks again.

[nikivanov]

Happy to help!

In terms of battery life, I'm using Liitokala HG2 at 3000mah, and there's two of them in the battery pack, in parallel, totalling 6000mah. It gets boosted to 5V and there's some loss there. The main power suck are the motors, not the RPi. I've never done an extensive test, but I would assume that at the highest draw, you should be able to get 1 hr continuous - that's all motors are spinning at full speed with some resistance. I'm really curious to know if this is a good assumption.

I used to use pigpio but had to go back to RPi.GPIO because I didn't have any hardware interrupts - both PWM and PCM are taken up by audio / mic. If you aren't using audio, you can (and should) go back to pigpio. In my experience, hardware-timed PWM is pretty damn close to actual hardware PWM. It should suit your needs.

The geared motors have axles in both directions. I was toying with the idea of adding idles and belts inside the rover, but decided it adds unnecessary complexity and cost. If I were you, I'd try to keep the belts inside, but outside would work as well.

[dclause]

Hi !

I receive the motors (see their 3D modeling here: https://github.com/Arduinolibrary/DFRobot_Micro_DC_Geared_Motor_with_Encoder/raw/master/FIT0450%20Solidworks%20File.zip).

Here are some thoughts on it :

1. The four motors don't fit on the rover. They are a little longer so that requires the bottom to be a little longer and the cover a little wider. I don't know how to transform the IGES file to something I can work on, I will try to learn that.
2. The dagu rover controller board will fit in the bottom part in place of the L298N. The screw holder though needs to be moved to fit the board size.
3. Electronics all works together and works with pigpio. I wrote the control in nodeJS and it works fine.
4. Your idea with the idler and belt would be good with one encoder-motor and a normal one on each side. unfortunately, the encoder-motor does not have a rotation tree on each side (only on the wheel side), so that solution won't work.
5. It also exists the FIT0458 (https://github.com/Arduinolibrary/DFRobot_Micro_DC_Geared_Motor_with_Encoder/blob/master/FIT0458%20Micro%20DC%20Motor%20with%20Encoder-SJ02.pdf). I wonder if that would be less changes to design a new holder for this and not touching the cover and bottom sizes...

So here is the current state. I'm currently stuck with the 3D modeling. I need to learn more on that subject.

[dclause]

Hello ! Okay, it took me some (long!) time to actually learn how to use a CAO tool. But it is funnny to do, so that's cool !

I could not properly redifine the sizes from the IGES files (I did not succeed in turning the IGES file to something I could easily change). So I learn anyway to use the software therefore I rebuild it from scratch.

Here is the new bottom : it is a little longer so the four FIT0450 motors feats in.

I am now working on the cover. But I do have a question though about the purpose of the two small holes at the back as well as the rectangular one. Both circled on the following picture. Could you let me know what are they use for ?

[nikivanov]

The ones at the top left give you visual access to the raspberry pi lights. The bottom right one can be used to pop open the case with a coin: besides securing the top and the bottom with screws, there are tabs that hold it by friction.

The CAD drawing of the motor with the encoder you posted has the axle on both sides - is that not the case for the actual motor that you have?

Since you're redesigning the rover anyways, you may want to consider N20 motors. They are more expensive, but have metal gears with different reduction and have a version with encoders: https://www.aliexpress.com/item/33016910240.html

Good luck with learning CAD - it's a worthwhile pursuit.