Showroom 3070W 6DOF Seat Mover (WIP Surge_Sway table)

It works, and the specs of this combo are pretty impressive. On the other side these are expensive gadgets

All credits to @vthinsel (original thread)

THe Platium Edition ( ), which I am using as vthinsel has suggested, shows some nice features. The Sabertooth 2*32A has a Baud rate of 115200 to the MEGA and the loops takes 0-1ms on MEGA only.

C&P from the original posting of @vthinsel:

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

I am using a LCD display as well:

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)

The next steps are to configure and to tune the settings.

I also use this setup on my 6DOF and just received the shield screen, its going to be much more convenient for the settings, its my looks good practice.
I will follow with attention.

@zigzag49 yesterday it was very close that I was demolishing the rig because of a malfunction (LFS was crashed and the rig bumped without braking into the wall) , so I advise you to find your optimal settings with caution

Now it works like a charm and no more dropouts. Review follows next week.

Ok thank you board.

To all if this information could be useful: real sway forces do not react well to traction loss. Either - or, not together because they are working against each other.
Shortly explained :

TL breaks out to the left side, if the back of the car in the game breaks out to the left side (driving to the right) , too.

The sway table breaks out to the right side if I am driving to the right.

I continue here, because I dunno if the issue is a SimTools, Ard oder whatelse issue. Please @Wanegain @vthinsel @yobuddy @value1 @BlazinH @eaorobbie @speedy have a short look at this.

After running into USB troubles (constantly loosing USB devices) I could sort it out - the issue was a wrong 2.0 USB driver (using one HUB was showing the behavior) .

As far as you probably know I am using the Ard (MEGA 2560) and Sabertooth (2x32) code from @vthinsel for the sway and surge tables. http://www.xsimulator.net/community...rduino-uno-mega-and-sabertooth-with-lcd.6747/

After a short time while driving on the rig the Ard (MEGA 2560) hangs, the Sway and Surge tables are both stopping at the same time. I have to disconnect the Ard or disabling/enabling in the device manager to get it working again.

This does not happen (!!) when I am using ONLY one table (BTW all other forces and motors are working, they are running on different bridges and ards).

This did not happen when I was using the SMC3 code and the vnh5019 drivers (Ard Uno R3).

Only if both tables are running the Ard hangs, mostly when I am accelerating and the sway tables goes to the right side (right corner)

Tables are stopping even if I reduce the power on the Sabertooth, so IMO no power supply related issue.

Settings of the Ard as @vthinsel in the original thread has advised.

Speed Ramping: 0.2s (Describe Software) -
K =0.30
Prop = 3.50
INt = 0.20
Der = 0.20

Thank you all.

Your Ard Mega is crashing ?
Is this an original or a copy ? I noticed some trouble with chinese copies sometimes when they need to send serial data (I think it's only in rx mode in this case)...

Can you see a red led (blinking maybe) on the Sabertooth ?

I don't change the K value, I only set Kp, Ki and Kd.

It is a copy. Had never troubles but you never know.

The red led is dead, already got in contact with the support but they said no issues are expected.

There is some reason for this?

The red led is dead ?? They don't want to change your Sab (dimension engineering) ?
Tell them there is a problem with the Sabertooth in serial mode, they changed all my 2x25 for 2x32

For the K, I think this value is needed when you use motors with different speeds. It's a factor applied to the result of the pid. But I don't think the issue comes from it.

BTW it is not crashing when one table force is disabled in SimTools. Only if both Axis are on the Ard hangs. Dunno if this behavior has to do with the timeout feature of the Sabertooth.

They said they would replace it on their own cost. But I decided not to do so yet (time, delivery, cost etc.)

This led is very useful for troubleshooting.
Are you driving only one Sabertooth with your Ard ?

yep.

Try to set a lower speed for the communication between Simtools and Ard (38400 for example, you need to edit the sketch).

Hi guys tried all except the lowering of the baud speed (too busy at the moment but tomorrow I will check this out), the behavior happened at the same place - the rig goes to the right side and at the end of the percentage range of simtools it stops.

Probably I should set the axis limits under axis limiting instead within the forces as a percentage.

Those two things I will test tomorrow. At least I will try out an Ard Uno R3 to be sure the MEGA is working finally (or not).

Any more suggestions are welcome

Regards
Pit

Is there any diagnostic programs that can be loaded to test Arduino's internal PLU's ?

I found this Loopback communication test plus the usual blink program .
http://forum.arduino.cc/index.php/topic,73748.0.html

If you are using the timeout feature now on the sabertooth is appears that it is not timing out. Therefore the ard is still sending serial data. And if you're still running vthinsels moded xpid sketch, the ard must be sending the correct data because it uses packet serial w/ checksum so it wont react to bad data. It sounds more like an issue in the sketch to me. But something else you could try since you still have two unused UARTS on the mega is to move the sabertooth to Serial2 or Serial3 instead of using Serial1 and see if the issue persists. Just change Serial1 commands to where you move it to in the sketch.

ps. I use 115200 baud without issue

I feel like you have some loose socket OR a bad USB cable that somehow when moving to that far right corner it causes the hang ... Sorry if it's just a feeling.

BTW : Is the Mega powered only by USB ? maybe the code needs something more .

Thanks @speedy I will check this tomorrow.

Hi @Pit, do you have a spare laptop/computer you can use to monitor the serial comms between the GamePC -> MEGA and then the MEGA -> Sabretooth. Or better yet since its a MEGA with multiple comm ports add some debug code to the sketch to confirm it is running the processing loop etc and print out one of the unused serial ports to monitor on the spare PC.

You will need a TTL Serial to USB adaptor (cheap on ebay) or you could use a spare Arduino for the purpose.

On the computer run a serial terminal such as termite (free): http://www.compuphase.com/software_termite.htm to monitor the comms or debug messages.

By doing this you should be able to find exactly which part in the chain is failing (unless more than one fails together?)