OpenSource Remote for VESC ArduBoardControl

Hi,

I was not sure about the design if it is ergonomic. So I printed it our and tried it out. I my point of view it is to thin and to wide. Sorry for that honesty. Something like the nunchuk is much more ergonomic because it is more palm sized.
 
Yes, thanks for the honesty. So of course it isn't going to conform to your hand like the nun chuck will but it is a trade off. The nun chuck would never fit in your pocket comftorablly where as this will. Also the nunchuck's size restricts the battery to a small capacity.

I agree with your comments about it being too wide and too thin. I have gotten those comments with a few other people. I plan to address that in my next revision. Also keep in mind that the print you did was an older model and I have since tweaked some ergonomic aspects.

Maybe you'll want to stick with the nunchuck design but I will continue tweaking this design until it is perfect. Also, you might be able to implement the Hall effect sensor and its mechanism into the nunchuck style housing. I can help you with that as well. Perhaps we could have two different style remote housings.

I have also started a topic on my website to keep track of housing design changes and I go in detail about everything. Here is is if you want to check it out: http://www.radicalcreation.com/forums/viewtopic.php?f=6&t=35&p=66#p66

Cheers!
 
HI,

For sure you should stay with your design! I'll concentrate at the moment on the software. At the next step I will go maybe on with an own design. I like your hallsensor approach. Maybe I will combine it with my magnet spring...
 
RollingGecko said:
Please don't forget the SD-card. We will need it to save setting after switch off. For example traveled KM. The feather has no EEPROM.
Click to expand...

This is a few months late but since @s28400 is using the feather in his latest prototype and I just read through this all, I wanted to jump in.

Via arduino.cc:
Part of the Flash memory may be used as a non-volatile storage with some limitations, the lifetime of the typical flash memory is about 25K write-cycles, and unlike EEPROM, and it must be erased in pages before writing. The flash memory is erased when you upload a new sketch.
Click to expand...
So I guess it just depends how much you think you'll write to it. If you did incorporate an SD card would it be weird to have it on the vesc side to save space in the remote?

Also I'm thinking about using this as a easy option for an oled: https://www.adafruit.com/products/2900 I'd have to redo your layout but I like that I could use some headers maybe (smaller than theirs) and just stack it on. I'm fine with having the screen sideways.
 
In my opinion you should forget all these oled and sd card things and add smartphone telemetry, or connect all this to jacobs bldc tool app, or both. Would safe place on TX side on RX side, everybody has a smortphone or two, we could make settings and see live data on the go <3 That remote would be better than everything available on this damn planet.
This is a great project so far, just my 2 cents.
And thx to Rollinggecko again for all your help, waiting for my new vesc's and hope this thing works for me :mrgreen:
 
Oh yeah, I guess I forgot about that SD card.

Also their color oled displays have as card holders. Perhaps this could work? Plus we would have color!
https://www.adafruit.com/products/1673?gclid=Cj0KEQjwncO7BRC06snzrdSJyKEBEiQAsUaRjJ0V8DE3MTkMrFdes77j9AihoqUYUuCVPJh4VjwnRQYaAkYK8P8HAQ

I could see about putting it somewhere else as well. Can the VESC flash be used as an self card? Ideally you'd want the settings to be saved on the boards side.
 
The smart phone is a terrible idea from a safety standpoint. I actually helped develop one last year and I can tell you it is scary to use. You need to have mechanical components especially for the throttle control.
 
I meant the smartphone just for telemetry, and to set up VESC. I also wouldn't like it to use a touchscreen as throttle:/
But keep going, tastes are different.
I like the arduio style, cause you can put that thing almost everywhere, and with the right code it's almost like lego^^ DIY!
 
Oh I see. Yeah I think an app would be awesome but I think it'd be nice to have info and the ability to change predefined modes on the remote as well. A lightweight vesc config tool in the phone app would be really awesome too like you said before. I don't think the information should be stored on the remote or phone but with the vescs on the board. This way you can use any remote or phone to check info and also save space and memory on devices. I'm not sure if we would need a separate arduino with the vescs or if we could do it on the vesc itself. Gecko would probably be able to inform us there.
 
The experience I've had up to now with bluetooth modules is, that they can have a connection only to one device (TX or Smartphone). That is the main problem I think. Maybe someone has other experiences. Then please share.
@isikxd: A topic are the writing circles to the eprom. 100.000. Is not much. I still have no idea with storing to the flash memory. I will read a bit through that topic. The SD-card is for me mostly interesting for telemetry. As said above, phone and Tx should not work together. Maybe you can use a bluetooth module to a smart phone and a nrf24 to the tx with an arduino as a switch...

But at the moment I will concentrate to the communication interface, the elimination of some bugs and...and...and...there is no end. Would be great if somebody can to join the programming site. :)

But it is great that all of you join the discussion. Keep going!!
 
Yes I believe bluetooth can only have one connection at a time. In fact I think the new boosted board actually has two blue tooth receivers on the board so you can connect a phone and tx at same time. Maybe we could do something like that. Also something we should look into is some kind of encryption for the bluetooth signal at least for the tx. I have no idea how hard this would be and it is something we can do once we have basic functionality.

@Gecko With the sd card, would that be on the vesc side and would another feather be fine for that or how do you think that should work?
 
I would not place an SD-card to the board site. Due to the vibrations on the board we can have here bigger problems with the connectivity.
An encryption is in my point of view not necessary. The bluetooth protocol guaranties, that only one device can be connected at once. And the VESc messages already have checksum for data integrity.

We should also not forget, that the idea of using bluetooth was to have a direct connection to the vesc without an arduino in the middle. If we start thinking now about:
2 bluetooth devices
encryption
sd-card etc.

on the board site we need again an arduino device on the board site or the requirement in implementation to the VESC. And if you want to use here a second bluetooth device or sd-card we need hardware changes as well.

That's why we should keep it simple and make "only" a UART connectivity to the TX over bluetooth (without an arduino on the board site) or nrf (with an required arduino). A subject I've tougth a while ago is to have bluetooth module on the Tx to communicate to a smartphone. Then the Tx is only a repeater. We can specify messages that could be forwarded directly from the VESC to the smartphone without handling in the Tx. We only have to encode the message type and wrap the message again in his body. All messages from the Smartphone are forwarded directly to the VESC.

But keep this as future music wide back in your mined.
 
Hi guys !

I was just wondering to add a simple 16x2 led display embedded on my board and I landed on this thread...
WWWooooowww !!! :shock:

You just threw stars into my eyes !! :mrgreen:
So I switched my Arduino Nano to a Feather BLE in my BOM, and hope to be able to help you in the development of this awesome remote/app.
Thanks for all what you do.
 
@Pimousse Awesome! It's great to have another member on this project!
 
Thanks !
Can't wait to see your Mark III remote !

I've just one question : don't you want to keep a reliable connection for the throttle ? (2.4 Ghz)
I mean using your hall sensor instead of potentiometer in a GT2b-like connection (PPM) and keep Bluetooth for telemetry and display management.
I'm so stupid to have ordered my Feather without waiting for the OLED to be back in stock... :roll:
 
Alright, I updated the model and 3d printed it. I wrote up a little report here: http://www.radicalcreation.com/forums/viewtopic.php?f=6&t=35&p=68#p68 There is also a video of the new features.

@Pimousse Yeah we could do that, bluetooth is nice because it pairs so there is no concern of someone elses remote controlling your board. Yeah they were out of stock when I ordered too. Check out Chicago electronics, they have them in stock.
 
Wow, your remote looks so good.best diy remote.
BTW I think gt2b afhds protocol is maybe also safe:
"Each transmitter has a unique ID,when binding with a receiver,the receiver saves that unique ID and can accepts only data from the unique transmitter.this avoids picking another transmitter signal and dramatically increase interference immunity and safety."
http://www.banggood.com/FlySky-FS-i6-2_4G-6CH-AFHDS-RC-Transmitter-With-FS-iA6-Receiver-p-922606.html

EDIT: ok, maybe not: "The stock module from FlySky is OK if you’re just controlling park fliers short-range (out to about 500 meters or so), but its Automatic Frequency Hopping Digital System (AFHDS) technology is fairly lacking if you want better range and robustness to interference. The AFHDS basically just searches for a free channel and uses that. Which usually works fine, but it could go disastrously wrong, for example if a new source of external interference arrives after the system has already started up and chosen its transmit channels."
http://www.rcgroups.com/forums/showthread.php?t=1869768
 
The vibrations actually is a good argument to keep the sd card off of the board side, I think my problem is just the space. I was hoping to use a nunchuck as well and I don't know where a sd reader could fit in there.
I do think the reader built into the oled like this one would take up less space. https://www.adafruit.com/products/684 But then if I were using the nunchuck it would be hard to get that any where near flush to be readable since the board is big and flat and the nunchuck is curved. I was hoping to avoid 3d printing because I have no access to a printer currently and zero 3d design experience.

Josh if you were willing to sell and/or send me a print of your latest version I'd build it out and try to jump in on the programming side. Right now I'm on vacation, but I'm trying to finish a parts list for this so when I get home hopefully I can order the parts (and my vesc will be shipped by then, fingers crossed) and I can get to joining in on this project.
 
s28400 said:
Alright, I updated the model and 3d printed it. I wrote up a little report here: http://www.radicalcreation.com/forums/viewtopic.php?f=6&t=35&p=68#p68 There is also a video of the new features.

@Pimousse Yeah we could do that, bluetooth is nice because it pairs so there is no concern of someone elses remote controlling your board. Yeah they were out of stock when I ordered too. Check out Chicago electronics, they have them in stock.
Click to expand...
Really great !! It seems to reach the release version.
Can't wait to see it working with the OLED info.
If I could advise just one thing : could you add a little hole at the rear bottom for adding a wrist strap ?
That would a shame to scratch this wonderful remote ! :wink:

Hillso said:
Wow, your remote looks so good.best diy remote.
BTW I think gt2b afhds protocol is maybe also safe:
"Each transmitter has a unique ID,when binding with a receiver,the receiver saves that unique ID and can accepts only data from the unique transmitter.this avoids picking another transmitter signal and dramatically increase interference immunity and safety."
http://www.banggood.com/FlySky-FS-i6-2_4G-6CH-AFHDS-RC-Transmitter-With-FS-iA6-Receiver-p-922606.html

EDIT: ok, maybe not: "The stock module from FlySky is OK if you’re just controlling park fliers short-range (out to about 500 meters or so), but its Automatic Frequency Hopping Digital System (AFHDS) technology is fairly lacking if you want better range and robustness to interference. The AFHDS basically just searches for a free channel and uses that. Which usually works fine, but it could go disastrously wrong, for example if a new source of external interference arrives after the system has already started up and chosen its transmit channels."
http://www.rcgroups.com/forums/showthread.php?t=1869768
Click to expand...
If you consider the short distance between the remote and the receiver (max 2m), then the weak point you mentionned is no longer interesting, that why for my point of view, GT2b wireless communication is the most reliable.
@sl28400 : No chance to have enough room (or thinking about a MK iV) for implementing GT2b PCB ? Using the same battery as feather.

isikxd said:
The vibrations actually is a good argument to keep the sd card off of the board side, I think my problem is just the space. I was hoping to use a nunchuck as well and I don't know where a sd reader could fit in there.
I do think the reader built into the oled like this one would take up less space. https://www.adafruit.com/products/684
Click to expand...
SD card is a such great idea !
Finally, we're just designing a remote which :
- control the e-sk8
- show info in live of the state of the board (avoid to fall out of battery).
- record data in order to improve the board or have data for a next project (range, power, speed...)
- Could play some music ? hum ? :mrgreen:

I'm in love with this kinda project ! :lol:
You guys rock !
 
Hi,

As I already wrote, I made a general design change of the communication interface. It is currently in a newFeature branch. The UART communication is ready and must be tested. Only thenRF24 communication is not ready and still a hard bunch of work because a protocol must be implemented and this then adapted to the interface. The problem is: At the moment I can't find the time and motivation to do this. :( Behind that are some considerations from personal site and community driven:

- it seams that long term nRF communication in this project is not in the main focus of the community. So maybe I will do all the work for nothing...
- There are so many features where I want to put my focus on, that the motivation for nRF shrinks
- Other for me personal important projects beside software wait for my attention (Publication of my printed board drive, A new carbon board with battery case etc., and, and...)
- It is summer!!
- I ordered a feather and that's the way I want to go in long term.

At the moment we have a working version of the nRF implementation (ArduBoardControl V0.6.2 with VescUartControl V0.1.4). There are some bugs only in the calculation of telemetric values that I can fix at next (When will not focus on nRF :) ). So ArduBoardControl V 0.6.x will be in future not anymore supported with new features. Sorry folks. I will switch completely to Feather/bluetooth.

If there is somebody out there who will take over the implementation of nRF to the new interface will get my support in explanation of the new interface and the planned design of the communication protocol for the nRF as well in testing.

As soon as I get my feather board and I setup my hardware, I will test the newFeature branch and bring it then to the master branch. The last stable Version 0.6.x of the ArduBoardControl (including the bug fix in the telemetry) will then be tagged and available as release. I will have then have a new major release 1.x.x with the new interface.

I hope you can accept my decision made.

Andy
 
If only I had some C++ skills, I'll be happy to give my hand, but for now, even if I spent hours and hours these last weeks to understand your code (you lost me when you switched to class... :lol: ), I just can read but not write code.

For me, it sounds quite obvious that you don't want to focus on nRF24.
The main advantage of Feather is the built-in Bluetooth protocol which could be used for designing an app on mobile phone.
It means that if we just add a BLE stack on the VESC with additional code to its own firmware, it's an incredibly feature improve of VESC.
And your work will serve much more people. :D (maybe Vedder could implement your code directly in the official firmware, BLE stack in option 8) )

As soon as I get all the stuff, I'm your man !
Anyway, enjoy summer !!!
 
Wow, thanks for all the replies! :D I did a few drop tests and noticed some problems. I have modified the model and am printing it now. It should be done within the hour! Here is the change log and I will release a more in depth update with tests once the print finishes: https://www.radicalcreation.com/forums/viewtopic.php?f=6&t=35#p69

@isikxd Yeah the vibrations seem like an issue for the SD card. I still firmly believe that the info should be stored on the board though. I mean as far as telemetry is concerned, we are only storing total distance traveled and anything else we want to log right? Perhaps we could interface some kind of external flash memory similar to what a USB thumb drive uses? That would hold up to the vibrations and shock. I'm not sure if we can use flash like that with arduino, just an idea.

Yes, I actually was going to offer anyone helping development a cheap early access model of the housing. I still have some changes to make but once I complete the initial durability tests, I will begin shipping the housings. I will also post the final parts list.

@Pimousse Thanks! Almost a release version but not yet. I was actually planning on adding a wrist strap similar to what the Wii remotes have. I will look into that for the next iteration.
I'm not sure on the GT2, I don't think that board would fit. I think the feather will work fine, we will see.
Haha, perhaps we could upload some tunes to our boards. Actually, you can use the motors as really basic speakers/buzzers if you send them a music signal through the motor controller. A lot of ESC's do this when they turn on.


@RollingGecko Good to hear! Did you get the same one I have with the BLE? I will ask around in my engineering lab and see if there is anyone with nRF/bluethooth experience that is willing to help. I have limited coding experience but I will see what I can do. One of the guys I know showed me this awesome handbook for arduino BLE a while back. It has all kinds of examples that teach you how to use it. I will see about getting that and I'll post it here as well. If someone with more code experience looks at it it would be extremely beneficial.

I'm really glad to see how many people want to be involved in this. With a project like this, it really is the more the merrier! :D
 
Here is the BLE Guide: https://docs.google.com/uc?id=0B8SUHnnHaP-aQnhFOWFsVzRyamM&export=download
I will read through it and try to work some examples. Anyone else who has and or is getting a feather, take a look at it too.

Edit: Also something I just saw gave me an idea for the future. So to configure the VESC after initial firmware flashing, instead of using the USB port, maybe we could use one of these: https://www.adafruit.com/product/2267 on the computer and change the settings over BLE. Just a thought 8)

Edit 2: I also was just reading up on the feather battery features and it has a built in voltage divider!!!! :D
Check it out: https://learn.adafruit.com/adafruit-feather-32u4-bluefruit-le/power-management#measuring-battery
 
s28400 said:
Here is the BLE Guide: https://docs.google.com/uc?id=0B8SUHnnHaP-aQnhFOWFsVzRyamM&export=download
I will read through it and try to work some examples. Anyone else who has and or is getting a feather, take a look at it too.

Edit: Also something I just saw gave me an idea for the future. So to configure the VESC after initial firmware flashing, instead of using the USB port, maybe we could use one of these: https://www.adafruit.com/product/2267 on the computer and change the settings over BLE. Just a thought 8)
Click to expand...

I'm willing to jump in on the programming when I get home as well so I'll take a look at that book, thanks. I'm going to order a feather now too and it'll hopefully be there when I get home. I'm more experienced with bluetooth and the uart protocal so I'm glad to switch from nrf, even though that is probably cheaper.

If you do decide to make some prints, send me a pm.

Edit: Saw as a possibility for the sd card reader. I don't know if this is true but it might be nice to have the rtc too for data logging purposes? https://www.adafruit.com/products/2922
 
You must log in or register to reply here.

Similar threads

B
    • Like
arduino nano ebike controller board (TSDZ2+VESC)
Replies
8
Views
2,723
djwlindenaar
D
mxlemming
    • Like
    • Brainy
    • Spicy
  • Sticky
VESC Tuning tips
Replies
15
Views
8,353
roscheee
R
R
QS-S4 LCD Display MCU
Replies
18
Views
14,653
13_CHIP_13
1
casainho
TSDZ2 EBike wireless standard (like Specialized Turbo Levo) - OpenSource
64 65 66 67 68
Replies
1,682
Views
143,257
tung256
T
T
Motor became stuck on, on a DIY dual VESC e-board setup
Replies
2
Views
1,539
TSG_AU
T
Back
Top