Synchronized lighting for VESC

Quick questions!

Your picture his the plug going into the debug header, but shouldn’t it be going into the uart header?

I have yet to play with @Ackmaniac’s firmware and an HM10 module, but I think using the UART port will make users choose one or the other. Can this firmware simply sniff the green Tx line for state changes if a bluetooth module is installed?

/edit

How could I add a second strip - one on each side of the board - that have duplicate functionality?

Ah… You right, the picture was wrong! Shame on me) I corrected this. Thank you.

The best option to work with bluetooth module and arduino on the same VESC uart is take arduino with two uarts. And connect arduino to VESC uart and bluetooth module to second uart of arduino, but this will need some code rework.

To add second APA102 led strip just connect it in parallel with first one to the d11 and d12 and gnd arduino pins(You, also, will need second LM2596HVS converter for second strip because one of this can take only 3A current.)

That’s good news! The second APA strip shouldn’t be a problem. I have one of these to supply the 5V.

1 Like

OK! So I got this up and running last night. Works great!

Some notes:

  1. I went and zipped up the sketch and libraries. Simply upload this zip file to the on-line arduino IDE, Arduino Create. Should compile right away and the FASTGPIO and APA102 libraries are already available. Works great and web access is nice!

  2. My arduino pro mini would not upload when connected to the TxRx of the VESC, even with the VESC powered down. I had to break these connections to get it to upload. Not the end of the world, just something to be mindful of.

  3. I had trouble getting the police_pallete to work. My LED strip is 29 modules long, so I changed
    ‘static const uint16_t CURRENT_PALLETE_WIDTH =29;’ I modified police_pallete too.

    const hsv_color police_pallete[80] PROGMEM = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 240, 240, 240, 240, 240, 240, 240, 240, 240, 240, 240, 240, 240, 240, 240, }; It works well now.
    RESPECT MAH AUTHORITAH!

    Should CURRENT_PALLETE_WIDTH = LED_COUNT?

Also, I had a thought about how to avoid using UART entirely. Could we attach the output of two of the motor hall sensors to INT0/1 to get the motor position? This might mess with FOC, but I’d bet that it wouldn’t.

3 Likes

Hmm, interesting, because I was able to upload firmware when VESC is powered down… Thanks for info, man, I must add these instructions to Github readme.

You don’t need to set CURRENT_PALLETE_WIDTH to LED_COUNT. CURRENT_PALLETE_WIDTH must be equal to pallete elements, for example, if you want to create new pallete with 3 elements: const hsv_color pallete_name[3] PROGMEM = { 0, 240, 0 }; or const hsv_color another_pallete_name[6] PROGMEM = { 0, 240, 0, 240, 0, 240, }; so CURRENT_PALLETE_WIDTH must be equal to number in [ ] brackets and count of values in { } brackets. :slight_smile:

Instead of this set #define LED_COUNT to number of leds on your strip(in led_strip_apa102.h file). And don’t forget change #define LED_STRIP_BRIGHTNESS to 31 in the same file.

That’s interesting idea, man, I think it’s possible, but only for sensored motors :roll_eyes:

Do you have single motor board?

Also, are you using old firmware on your VESC? I’m asking, because I tried to use HM-10 bluetooth module(with many apps at google play) and can’t get any data back, because of outdated protocol I think…

p.s. Could you, please, record a video? I have too many snow on the streets in my country now, so I can’t get joy of this.:sweat_smile:

It just snowed here last night, so ice and salt and water everywhere. :frowning:

I can take a quick vid of it on the bench in my disaster of an office/workshop.

I’ll play with the settings tonight and document what I do and how it works.

I’m running the lastest vesc firmware from vedder - I need to dig out my HM10 module and flash the ackmaniac FW and see if I can get it working.

Yeah, sensored motors only, but I’m running @12S and the cord is just dangling there.

1 Like

you seem like a busy guy :stuck_out_tongue_winking_eye:

Yeah, i get around. Problem is the CNC is stuck at work and i have a few hours at night to kill when I’m home. :slight_smile: i got the G-code sorted for your cuts, but had to tweak some operations for the trucks mount. Geometry is unchanged, but i need to pocket a large area to prevent a rouge piece from coming free and breaking the bit which has happened before. I’m going in a few hours early tomorrow to try and bang out your parts.

haha no worries bro. just teasing you because teasing is fun :wink:

1 Like

Also interested in using my bluetooth AND an arduino on that serial line…

Got it up and running on a couple Arduinos, it’s rather sweet. A thought, would it be possible intercept brake signal(from ppm maybe) and flash red Will try to grab a video over the weekend :yum: Btw, I’m using the 144led/m strip

I already have a script running that reads a button press on channel 3. Hoping to use a button press to turn the lights on and off as I don’t want them on during the day.

I bet we could attach channel 2 to to INT1 and get throttle position, but that would eat up all the hardware interrupts and I’m thinking that reading hall sensors is the way to go to get around UART.

Here’s the script:

#define BUTTON_SIGNAL_IN 0 #define BUTTON_SIGNAL_IN_PIN 2 #define NEUTRAL_BUTTON 1500 volatile int nButtonIn = NEUTRAL_BUTTON; volatile unsigned long ulStartPeriod = 0; volatile boolean bNewButtonSignal = false;

void setup() { attachInterrupt(BUTTON_SIGNAL_IN,calcInput,CHANGE); Serial.begin(9600); }

void loop() { if(bNewButtonSignal) { if(nButtonIn > 1500){ Serial.println(“ON”); } else{ Serial.println(“OFF”); } bNewButtonSignal = false; } }

void calcInput() { if(digitalRead(BUTTON_SIGNAL_IN_PIN) == HIGH) { ulStartPeriod = micros(); } else { if(ulStartPeriod && (bNewButtonSignal == false)) { nButtonIn = (int)(micros() - ulStartPeriod); ulStartPeriod = 0; bNewButtonSignal = true; } } }

Code Source

2 Likes

I was actually just thinking, why not use ppm for everything? And/or why not put a sensor on the Arduino to sense the road moving by or motor/wheel spin? Can be vesc/ESC independent then

Essentially yes. We want to see what the motor or wheels are doing so that the lights are synched to the actual motion of the board. Polling the VESC via UART gives that, but there are other ways of getting that info.

I think that reading a hall sensor is most likely the easiest way as the motors have the hardware built-in and the VESC is simply reading the values. If we can sniff a single hall line we should be able to determine the RPM of the motor without interfering with FOC.

I’m thinking of making a PCB to knit all these ideas together for testing.

Yeah but that assumes having hall sensors…I have em, you have em, not everybody does though :thinking: And right now it’s vesc only Is it vesc6 compatible?

True. Maybe have a code base that allows for different control methods?

  • Trigger Monitor
  • Hall Monitor
  • UART Monitor
1 Like

I just got these awesome lipo charge+boost boards, will be making mine independently powered

3 Likes

Wouldn’t reading the ppm be kind of easier. Just use a y servo cable to split the signal to vesc and arduino. Maybe drop an optocoupler before getting to the arduino to be safe. Arduino already has libraries to read the servo signal That’s what I was planning on doing on the future at least

The only thing with ppm to take into consideration I think are the calibration values used by the vesc, there should be a way to input them , min, max, deadband

1 Like

Hmmmmm…