Go in industry and tell to automation guys that they’d better use communication to drive motors instead of 4-20mA signals, with the same self-confidence. Come back and tell me the way they welcomed you.
I design automation systems embedding VFD drive fans which keep safety air pressure for underground workers exposed to radioactive hazards.
If one fails, lives are in danger. Evacuation is triggered.
For those reasons, driving motors by communication is FORBIDDEN.
Reliabilty and redundancy are the key.
However, I’m really bad about designing mountainboards. That’s not my job.
So I can’t have the arrogance to tell you that it’s better to design a deck this way or this way and nobody should ride other shapes.
It is possible to identify connection issues of a PPM remote which is called Failsafe (my firmware mod can handle that, but not easy to understand how it works and can be configured)
When a signal loss or failsafe is detected the board shouldn’t go into immediate coasting of predefined braking. It should ramp there otherwise you have no chance to adjust your body to the situation and crash. (My firmware mod does that as well)
And it should ramp as well back to power when the signal is back.
Saw a couple of people crashing because of that (very experienced ones as well @Nowind).
With the NRF you can control multiple ESC’s at the same time if they use the same address, so it would be possible to have 2 receivers for redundancy but a bit tricky if you still want traction control.
In order to create the most reliable system, you need to sketch down what possibly can happen and then find the solution that has the lowest chance of failing under all circumstances. With DIY builders you don’t know exactly which receiver they use, if that has fail safe, how good is the enclosure, what motors are use, cables connectors, batteries, BMS etc. Designing a system where you can define all components is something completely different. Then there is also theory and reality… From all remotes we have tested so far, the NRF based ones are the ones that work flawless and do not need configuration in software. You pair them, they work and batteries last for ages.
@Ackmaniac Failsafe on PPM is a feature of the receiver, basically sending neutral command or 120% command. And it is specific and different for different receivers. The downside of that is you need to trust the receiver to always act perfectly like you expect it to do. We have no insight into how exactly those receivers work, since they are a black box and FW is not public, and most of them are not designed for purpose. Also people can do configuration wrong and think they have a good failsafe, while in reality it doesn’t work. It all comes down to the quality of the receiver, the remote and the users abilities, so we have two - three variables in such a system and still the VESC and the PPM receiver do not communicate. ESC simply takes signal and doesn’t know what is going on in the communication. ESC is passive receiver of commands and needs to trust commander blind.
The NRF FW is OS and we know exactly what is going on there, it is not a black box. We can define the way it interacts and we can implement appropriate features for fail safe. Many eyes on the code spot bugs faster and improvements can be done by multiple coders.
Using a automatic failsafe brake is very debatable. In some situations it might be a good feature, in others it might cause more trouble than you already have. Soft ramping is a good idea for the fail-safe brake.
This is all a bit off topic. It would be best to open a thread about such things:
Redundancy and safety in skateboarding
Hi @keithcys, motor current can be done via profiles, which is for both VESCs.
If you configure the currents and battery limits during setup, and write settings, you do all VESCs in one hit.
Edit: If you do changes in motor and app config, it is per VESC.
You can still connect to single VESC and change individual settings via CAN forward.
All the coding for the VESC tool is being done by Vedder not Frank.
How does timing a software release have anything to do with the subject?
taz:
I think you are being unfair now.
A. All the coding for the VESC tool is being done by Vedder not Frank. So any problems you have with the fw should be directed at him. It was already mentioned by @rpasichnyk that it is Vedder that does not care about backwards compatibility.
B. Not only focboxes were affected by the change that caused the escs to brick. The fact that you heard more about them is due to the fact that i) they are the most used esc in this community ii) they lack the pins to connect an ST link to upload the bootloader so it is even more of a hassle to solve the problem. I should know, I was one of the lucky guys affected.
C. I don’t see how he told off half his customer base. If you stick to using vesc based hardware with the VESC tool there is no problem If you want to use 3rd party apps you need to make sure they are compatible before proceeding.
D. The solution to this problem has already been mentioned multiple times. 3rd party apps should check fw version before doing anything.
Maybe Vedder does not make it easy for 3rd party app developers (and in my opinion he should) but I don’t see anyone else (apart from @Ackmaniac) writing firmware if you don’t like Vedder’s.
You do realize that even original VESC6 would be affected by the change, do you? Or are you saying that Trampa deliberately made Ben change the code risking all hardware to brick and showcase the lack of pins on the Focboxes? A little far fetched don’t you think?
taz:
If you stick to using vesc based hardware with the VESC tool there is no problem
Funny you should say that.
Here is an excerpt from your car’s warranty:
With DIY, even more so, there are more chances of various components not working in harmony together. Regardless, I have already stated my belief that all developers, including Ben, should make it easier for everyone else to do changes.
taz:
The solution to this problem has already been mentioned multiple times. 3rd party apps should check fw version before doing anything.
Again, the vesc tool has been performing this basic fw check since the beginning. If all other tools did the same nothing would have happened. The firmware worked just fine with the original vesc tool.
Actually, you more or less accused them of deliberately changing the code to brick vescs.
It is more than evident that your dislike for Trampa does not let you see things clearly in this case.
Frank, please can you tell if the new module can work with the firefly remote or feather remote? I already asked this, just a friendly reminder.
This remote has been self assembled hundred times from builders in this forum.
I’m pretty sure you know them
I absolutely did not, I simply said it was convenient for Trampa. I leave you to draw your own conclusions.
Once again, incorrect. I have complimented and encouraged Trampa when they have done good things, its just rare that they do good things for the community.
Hi @surfer, this remote uses the NRF 24, which we started with when making the VESC6 some years back. This chipset has some downside to it and we went for a better chipset to allow more data to be transferred. When Benjamin banged on VESC-Tool mobile, it was clear that you want one module to handle all tasks, communication to phone and communication to remote and more data throughput.
The NRF51288 allows to have communication between phone, remote and esc simultaneously, which is a big advantage. The amount of data that can be transferred is way higher and in respect you get better real time data and firmware updates can happen wireless without you falling asleep.
On Wednesday I’ll have a last chat about the NRF with Benjamin remote and then we will make something available fast. Benjamin and I are totally convinced about the NRF51-Remote.
In his latest video he shows a prototype with basic functionality. We hacked that together to do some more R&D…
What is possible is a connection to a NRF24 receiver, using the NRF51288 remote. In practice you want a NRF51288 VESC-Connect dongle in your board, unlocking all the new features. Small invest, big difference!
That question is for the people maintaining the firmware for the remote. They can look at the changelogs and determine that. Actually they should test and tell you that. So this question makes sense to be posted in those threads.
It’s unreasonable for Benjamin to test every third party stuff out there.
You can always downgrade to the last version that your hm10 module worked.
In fact, I am thinking about doing that on the board that has the metr pro module, until Roman modifies his app. The board worked just fine, so I see no problem staying on the previous fw.
Personally I think the 51822 is very affordable and super useful. The advantages are on the hand and one module handling everything is saving a lot of pain to wire things up. I have no doubt that these modules will be the standard very soon.
@b264 two modules paired to one remote work. Real time data will be streamed via one VESC only.
).
taz:
)