New XPID software for Arduino UNO/Mega and Sabertooth (with LCD !!)

Hello !!

So I have decided to start a new thread beside the 2DOF seat mover thread I initiated in order to discuss the software setup. The idea was to use an arduino with a sabertooth module which is a setup that is more and more used. I used the great code from wanegain as a basis and I started to discuss with him (the PM thread is 8 pages long now... and still growing everyday )
We decided to improve the current setup with a LCD device to monitor/debug the runtime environment, but then we added support for the sabertooth 2*32, and later on we added support for Arduino Mega. All that with a single code, whatever the sabertooth module / arduino board you select. The LCD has a menu driven interface to configure the various parameters.
I tested on a UNO and a MEGA, both with sabertooth 2*32A (set to 115200 with MEGA and set to 38400 for UNO). The loop takes 0-1ms on MEGA and 2-3ms on UNO. Should work out-of-the-box also on Sabertooth 2*25A

Main advantages of Arduino MEGA 2560:

• 4 Serial UART, allowing 115200bps end-to-end (one used by USB, leaving 3 full COM ports for your design). This means we can achieve sub 1ms latency between SimEngine output and sabertooth input
• LCD/Keypad Shield compatible
• Lots of available pins (both digital and analog) to add a TM1638 dashboard for example
• 256Kb flash / 8Kb SRAM / 5K EEPROM (versus 32/2/1 for a UNO)

Main advantages of Sabertooth 2*32

• USB port to configure/monitor
• 115200 Serial packet mode (with CRC)
• same price as 2*25 !!!
• Intelligent user mode to implement specific behavior
• Can absorb regenerative current using resistors

Many many other features .....

The "platinum" setup is of course with an Arduino Mega 2560 and a sabertooth 2*32 but others should behave well also

The LCD will allow you to

• edit all PID parameters for each DC motor
• edit your pot min/max/deadzone values
• edit your global deadzone
• change the sabertooth type
• Set standby values for each motor
• Change number of reads done on pots (average system)
• Reset EEPROM to default values (recommended for first time load)
• Show in realtime the value sent by SimEngine, the PID value calculated and the pot value (as well as loop time)

All parameters are written to EEPROM so they are persistent of course.

The LCD/Keypad management requires some cycles (which takes 10ms roughly), so in normal condition it should be turned off. There is a switch to install to make the LCD silent (it will also shut down the backlight).
An additional feature has also been added : a standby position can be forced by an additional switch. This will allow you to put you sim in a known position whatever happens

Enough writing, here is a demo !



The pinout to wire everything :

Pin out of arduino UNO for Sabertooth
--------------------------------------
Pin 3 - Sabertooth S1
Pin 2 - Switch to enable/disable LCD. Switch open => LCD ON. Switch closed to GND => LCD Off and backlight Off
Pin 12 - Emergency switch to disable DC motors between. Switch open => Motors ON . Switch closed to GND => Motors to standby value
Pin A1 - input of feedback pot positioning from motor 1. (5V,wiper,GND)
Pin A2 - input of feedback pot positioning from motor 2. (5V,wiper,GND))

Pin out of arduino MEGA for Sabertooth
--------------------------------------
Pin TX1 - Sabertooth S1 at 115200bps (serial packet mode)
Pin TX2 - Debug output at 115200bps
Pin 53 - Switch to enable/disable LCD. Switch open => LCD ON. Switch closed to GND => LCD and backlight Off
Pin 52 - Emergency switch to disable DC motors between. Switch open => Motors ON . Switch closed to GND => Motors to standby value
Pin A14 - input of feedback pot positioning from motor 1. (5V,wiper,GND)
Pin A15 - input of feedback pot positioning from motor 2. (5V,wiper,GND)



In addition, all grounds should be connected : sabertooth/arduino/any device (arduino scope for example)

3 additional Arduino libraries are needed:
- Sabertooth library
- MenuBackend
- EEPROMex

For Sabertooth 2*32, configure additional parameters using describe software as shown in the video below, which also demonstrates the system reactivity



From a bench point of view the PID response looks good to me, the deadzone works as expected. Now I'll really think to build the rig, as the software looks good and stable to me.

Some other pics here

Time to play a bit now !

EDIT: version 3.13 online. This will be the last version with LCD support. Next one will be for TFT+touchscreen. I may update bugs in this version, but no more features will be added.


EDIT: version 3.15 online. This is the TFT+touchscreen version. Should you choose this version, get also the XPID_SimTools_3.15_libraries.zip file otherwise you just need the XPID_Arduino_libraries.zip file

EDIT: version 3.20 online and on github for further updates https://github.com/vthinsel/XPID. Use libraries in file XPID_SimTools_3.15_libraries.zip

Congratulation! The Ard's are more and more growing up. Thank you for this new code and effort.

Very impressive!
The link to this topic is added to the Arduino FAQ

Here a touch screen + arduino @11$

That's a pity that Arduino clones are often not trustworthy...

http://www.banggood.com/UNO-R3-ATme...T-LCD-Screen-Module-For-Arduino-p-945755.html

So far, so good with clones. I have ordered some from different vendors in HK, and I haven't experienced issues so far. Time will tell...
I tried 3 Uno (some using the DIL, some using flat package), and also 3 Mega. All worked (except one Uno which I had to reflash the bootloader).
The touch screen is nice, but I'll really move away from Uno, as it is quite limited in terms of memory. Especially with such a nice add-on as the TFT touch screen, code will tend to grow a lot....
I'll post today the code and libs. No bug fixes done yesterday, behavior is good

Soooooooo....
Version 3.11 is attached to the first post, and I'll keep editing it so the latest version is always on the first post.
Feel free to give it a try and give feedback !

Merci pour ce beau travail,
J'envisageai de faire quelque choses de similaire avec une UNO et j'ai acquis pour ça une carte Ethernet, ton code sera probablement adaptable ?

Thank you for this beautiful work,
I plan to do something similar with UNO and an Ethernet card, your code will probably be adaptable?

Why do you want native ethernet ? To have ethernet between SimEngine and Arduino ? Better immunity across mong distance ?
I played sometime ago with a Mega128 and an ethernet module based on a wiznet chip. It was really slow : managing a TCP/IP (or UDP/IP) stack is very time consuming especially for so low speed devices such as AVRs. Timing and lowest latency is key in such projects, so I wouldn't feel very comfortable with ethernet/Arduino combo (maybe an arduino zero would be better, ARM based). With a RS232/USB serial link we can reach 1-2ms latency with this code which is fair. A simple ping, which is ICMP protocol already takes a couple of milli secs. Not to mention the code/flash space used by the IP stack. Go for arduino mega !
Beside this, the arduino communicates with the ethernet shield using SPI : a serial link
If you want to stack shields, you must also make sure the LCD and Ethernet shield do not use the same pins. The LCD shield uses 7 digital + one analog. So there are not many left for another shield (not to mention the needed pins for sabertooth/pots/switches). Once more, the Mega would be a better option.
Ethernet would be nice to manage a nice web page to configure the PID, and thus replace the keypad of the LCD. But it shouldn't impact the timing for the PID loops

hey @vthinsel first of all congrats for your achievement! Really impressive!
Second, could you tell me how to reflash the bootloader of an UNO? I had a problem with a clone one (out of three), too.
Thanks

I have an AVR ISP MKII programmer, so that is easy . Just follow the regualr procedure http://playground.arduino.cc/Learning/Burn168
It loosk like there are some ways to program the UNO bootlaoder using another UNO, acting as a programmer.
Found that : http://www.gammon.com.au/forum/?id=11635
and that http://arduino.cc/en/Tutorial/ArduinoISP

Ne connaissant pas grand chose dans les micro-controleurs ce sont ces mêmes seuls arguments que j'aurais pu avancer.
Merci pour l'info.

Not knowing much in micro-controllers it is these only arguments I could move forward.
Thank you for the info.

Un autre élément (peut-être pas heureux ?) c'est la possibilité sur la carte Ethernet de mettre une micro-SDHC

Another element (maybe not happy?) Is the ability of the Ethernet card to a micro SDHC

Yes, but they are exclusive. At a given time you can use either ethernet OR micro SD. This adds complexity to the code and adds overall slowness.

Merci.

Here is a pic of the connections for an arduino Mega (except for the LCD shield )


I'll also make the same for Arduino Uno

Merci je vais peut être réussir a faire fonctionner mes smolka arduino uno et sabertooth 2*32 car je galère pas mal

Thank you I can be a successful run my smolka arduino uno and sabertooth 2 * 32 because It's a little bit hard to do

The LCD screen is usefull in such case for debugging. Can be done on serial link as well, especially with the Mega2560 but I haven't implemented that yet, only basic debugging: no real time values.
First step is to get values from SimEngine (LCD can help), second is to get values from pots (LCD can help), third is to make sure commands are sent to sabertooth (you can hook the TX pin to a regular com port on your PC to see what commands are sent), fourth is to make sure the sabertooth is correctly configured.
I'll post a sample of RS232 packets sent to sabertooth, for reference.
Good luck !

BTW, I can also write in french if needed but I'm lazyyyyy

Hi there !
The rig construction is moving slowly but surely. I did some code updates which I'm currently testing, especially around the ADC conversion. In most codes around, the FASTADC mode is used. As a side effect, the measures are quite imprecise, requiring to read several times and make an average.
With FASTADC and 8 reads, I came up with a fluctuating deadzone of 3-4, but sometimes some glitches of 5 to 10 !! In that case the control loop takes around 1ms.
With FASTADC disabled, and sample time of 1, I get a solid deadzone of 2 ! The control loop takes also around 1ms (I should look at decimals, but anyway too much samples seems to impact PID calculation in a bad way if I understood correctly).
The choice is one accurate read versus several "bad" reads.
Could someone advise on the FASTADC and its presence/necessity in code ? Maybe related to the pot moving while being read ? Is the same true when using hall sensors ?

Stay tuned for version 3.12 very soon