Dynamic Controls Power chair, RC Boat trailer project

[woodygb]

Tony ...
My mods seem to have solved the communication problems that I appeared to have been having .
The chair has so far ...in VERY limited testing ... shown no problems..

[gcebiker]

Well ...mine is alive!!

[gcebiker]

Biggest difference i can see between the Yellow boards and the blue ones ..same code.

Is that the trace to A is much thinner on the Blue boards (perhaps too thin..), i am going to try hard wiring it from the 22k resistor tomorrow.

[woodygb]

Here is my current working code ...very similar to your original.
As mentioned previously I also added the mods to the board .

SR_RC_PCB_Board_March_3_2018_woodyonoffworking_copy.zip

(4.99 KiB) Downloaded 291 times

[woodygb]

Edit ...seems the post that this reply is to has disappeared...Ah! it has reappeared below!

No ...
The fact that they measure High or Low has no bearing on their designation.

The data is sent down the wires differentially, or when one wire has a high, the other wire has a low and vice-verse.

Look at my drawing and the embedded text quoted from the Dynamic Tech sheet.

[gcebiker]

Improved drawing ...previous deleted.

The attachment tony mods1.png is no longer available

A/B are the designations for the MAX485 pins, i am thinking my labeling on the terminal connectors is misleading.

B is "HIGH" on the Shark Bus, B being the name of the pin out for the MAX485.
A is "LOW" on the Shark Bus, A being the name of the pin out for the MAX485.

[gcebiker]

Amended A/B

[woodygb]

OK ...That new drawing does indeed match your boards A and B.

[gcebiker]

Your code also works with my transmitter ... timing is still out tho, I definitely need interrupts and a start value for speed, direction.

Its waiting to long for the pulseIn, code works but the chair is only running in LIMP mode.

[gcebiker]

2. Data format
The data shall be transmitted in standard asynchronous serial format as supported by the UARTs on microcontrollers. The data
rate shall be 38400bps, with 1 start bit, 8 data bits, and 2 stop bits. With updates every 20ms, this allows for 69 bytes to be
carried on the bus for each update (assuming 0 delay between bytes, which is not likely due to microcontroller processing
times). This means that if the SR sends a total of 20 bytes, there is time for 49 from the SPM. 38400 is the fastest data rate
which can be accurately generated by most microcontrollers with 8MHz crystals, and it is a rate which can be directly handled
by a PC serial port.

Ill re write the code today or did you have interrupts already written woddy ?

[woodygb]

I have some code for interrupts but have not ported it over to the Dynamic sketch.

The problem is ..I.M.O ... not the read time but the R/C signal period which is SET @ 20msecs... so 20msecs is the fastest that you will get.

So ...if you want a different signal period read time... I think that you may need to store the R/C signal or a rolling average of the R/C signal...( only 2 or 3 signals ) ... and then READ it from memory every X msecs and output this to the Dynamic module via the Arduino code..

Quick note about limp mode.

Mine enters limp mode only if I turn it OFF then ON again without waiting.

[woodygb]

I'm going to add measurement of the Dynamics OFF code to my "to do" list...just in case it has a format similar to the start up.

I.E. Pulse repeated for OFF and ......?

[gcebiker]

Added the resistor/diode / 5v, beefed up the trace to SBL 'A' ...still faulting but working, i am sure its a timing thing.

I plan to use interrupts to update "on/off, direction, speed pins values" (reading now how do that bit of code)

Remove "directionPotVal = pulseIn(directionPin, HIGH);" & speed from the "void sharkOnMode()"

The Shark Power module takes care of the smoothing in the 'Wizard' Setup.

Something like

Code: Select all

Words for monitoring input pins (the interupt)
 if "Code if the monitored pin has information available"
     onOffVal = Monitored interupt pin new data
          if (onOffVal < 1300 && onOffState == HIGH)
  {
    onOffState = !onOffState;       //toggles onOffstate from HIGH to LOW (if it was HIGH when the on/off button is pressed)
    digitalWrite(led, onOffState);  // Turn off the LED on arduino as indication of state
    digitalWrite(dePin, LOW);
    delay (100);//
  }

Just so that the code is not sitting waiting that 20ms (three separate times in the code)

[woodygb]

Here is an interrupt code for 3 channels.

It will display 3 values for the R/C signal and the number of times each channel has completed a Low -High cycle in time X.

A completed cycle in time X ....is called a COUNT .... count time is defined by a const long interval = X msecs ...it is currently set at 21 which is the shortest time that I could get a reliable COUNT reading...which is logical considering the R/C time period is 20msec.

rc_interrupts_3_channels_working.zip

(1.56 KiB) Downloaded 301 times

[gcebiker]

[woodygb]

Once again I postulate that no matter how fast you could read the R/C signal it is always going to be driven by the code in the Arduino having to currently wait for the R/C period to finish.

I.E. Read a channel ...this takes a minimum of 20msecs ...transfer the result to the speed and or direction code ...compile and output.

[gcebiker]

Its ok, its only going to update every second data packet along the Shark Bus.

yes its going to make for inconsistent timing.

The thing that is bothering me is that in March Last year i had it running the same code but had to add the delay to slow it down.
I will update my Arduino IDE, perhaps softwareSerial is adding to the already expected pauses in code.

[woodygb]

It seems that you are resistant to the 2 resistor mod that I suggested for the SBH B ... why not give it a whirl?

[woodygb]

Is this your missing code?

SR_Emulator_mapping_attempt1.zip

(4.35 KiB) Downloaded 294 times

[gcebiker]

It seems that you are resistant to the 2 resistor mod that I suggested for the SBH B ... why not give it a whirl?

Lazy...

Ive all the code its just bugging me why it 'stopped working' or working but timing went out.
Gives me something to do, trying to nut it out.
Thank you though.

Thats a very early version of the code, i was getting to much jumping around using a Pot, so changed over to Nintendo Wii.
https://www.youtube.com/watch?v=6GkNFPJ ... PWs-7ruHkA

[gcebiker]

It seems that you are resistant to the 2 resistor mod that I suggested for the SBH B ... why not give it a whirl?

Well lazy and its working but the timing it out and thats a code issue i need to identify.

pulseIn is bad practice, delay() is bad and the code is messy as hell....its not a bad thing to get it a bit tidier/faster.

I should also get it reading the packets from the Power Module...but baby steps.

[gcebiker]

Now that i think about it a bit more....

I think i got the timing right with the Wii Version...and then did not check it with later RC versions.
That first video i made backing the boat...it was the first time i had driven it, so i went super slow, thus the fault did not rear its head...
...my driving got better, and my thinking was that the faults were with the batteries/load but now i know its the pulseIn.

Maybe i need to use serial RC receivers (as you point out Woody, even using interrupts, its still going to take the pulse time to update)

I vaguely remember somewhere....i watched a video on someone hacking a PPM Receiver to get at the serial data before the PPM encoding...
Undoubtedly it was on YouTube and some time ago...anyone heard of it being done ?

[woodygb]

Moved the sketch over to Altsoftserial.

NOTE:- Altsoftserial requires SPECIFIC Pins TX = 9 & RX = 8 ...So ...I pulled your existing pin 6 ( RX ) UP above the board and jumpered across pin 6 to 8 on the Blue board ... thus I could simply jumper back to the original config if needed.

altserial_woodyonoffworking_copy.zip

(5.14 KiB) Downloaded 288 times

[woodygb]

I'm NOT sure if this will work but I have attempted to add a repeat of the sent code to the sketch .

NOTE:- This sketch is using AltSoftSerial.

repeat_altserial_woodyonoffworking_copy.zip

(5.34 KiB) Downloaded 304 times

[woodygb]

Very minor update to the drawing I made for the A-B pullup and pulldown.
I forgot to mention that I had added... on a whim ... a 47k pulldown resistor to the DG419 Switch pin.

[gcebiker]

This is A version of the Wireless Wii Nunchuck code from this video....just in case it takes me two days to find it on my HDD again

SR_emulator_software_serial_Wii_Input_tink.zip

(4.79 KiB) Downloaded 293 times

youtu.be/6GkNFPJlW4c


Pins in this sketch are different to those used currently....its an older sketch on the first prototype board.

It will work with Wii wireless and Wired Nunchuck's, should alleviate the data speed issues with PPM

[woodygb]

The R/C timing issue can be dealt with in programming by having CONSTANT channel values in memory and accessing them via a signal duration timer suitable for the Dynamics requirements...this is unfortunately LESS than the R/C period.

So the logic for the CONSTANT channel memory would go something like this .

CONSTANT channel memory = PREVIOUS VALUE or CURRENT VALUE

E.G.
IF the channel has NOT changed in X msecs then the Dynamic signal procedure will use the previous value.
ELSE IF the channel value has changed in X msec then the Dynamic signal procedure will use the current value

Hope that makes sense.

[gcebiker]

I spent a lot of yesterday trying to find the 'timeout' value that would work for such a thing...and still be with in the timing needed.
It worked for one ch but not both, then i kicked around using a boolean and getting a read every second cycle but the values returned if it timed out where waaaaayyy off.

I figure a better way to do it is with a second Arduino/I2C but getting an SBus receiver would work easier and faster.
Ive not got one at the moment so working with the bits in the shed.

Wii 2.4Ghz
RF24 modules
Arduino ATiny pro's, and Nano's if i want to try out using two processors.

The boards are Pi Hats, a Pi could handle the separate processing with out impacting on the timing...but i don't have one laying about.
..and its over kill.

I need a small transmitter that can be easily waterproofed (stuck in a zip lock bag), the Wii may not have the range out of the box but i wont know till i try it out.
I should have some results in the next day or so.

I use the Wii joysticks for our Sailability boats, they are fantastic.

I am still looking for the video i watched once where the PPM plugs were bypassed and the signal passed with one wire.

I will open up an RC receiver and plug the logic analyzer in to see what i get if i cant find the video.

[woodygb]

I'll try and knock up a complete sketch for you to try over the next few days.

[gcebiker]

I'll try and knock up a complete sketch for you to try over the next few days.

Timing is too critical, using an SBus Receiver seems more robust.

Wii Code is finished...sort of (need to figure out fail safe section of 'void loop ()' )
-- Tested and working (at least around the lounge room).

- Many notes taken out, to make the serial data packet creation sections cleaner to understand.
- Many notes added, reworded.
- Value 'pot' replace with 'pin' to better reflect the inputs.

- void setPowerPins () , for powering the Wii not used but included in this version of the sketch.

RC (commented out) and Wii code included in the one sketch, for Blue board V3.23 ( link to Dirty Cheap PCB board house included in the sketch).

SR_emulator_software_serial_Wii_Input_n_RC.zip

(14.06 KiB) Downloaded 227 times

Current timing leaves room for data read of Power Module (i hope...well there is 5-7ms of time available)

Per notes in the code, Wii 2.4Ghz receiver powered at 5v from Arduino is too high
(it works but with joystick at full deflection it registers reverse of intended direction)
DC-DC converter required or power from 3.3v output of Arduino (if it has one and able to supply required current)

As the Wii remotes are much much cheaper than SBus gear, if a person wanted the form factor "X" it would be very easy to swap the innards of the Wii Transmitter over, giving better battery life, room to enhance the antenna, and more control/throw for pots.

This sketch will also work with wired Wii Remotes (minor sketch changes)...which are very very cheap (if you wanted to sit in the chair you were controlling)...i drive myself about in my chair in the lounge room during testing
.
.


.