-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EspressLRS support (CRSF decoder) #24
Conversation
Nice video, good job. Now i have a problem with this pull request :-/ I really do not like this non-objectOriented #ifdef chaos of the EFeru FOC Gen1 firmware with all the many With my C++ SimpleFOC firmware i go for an abstract base communication (= Pilot) class and begin with a PilotI2c: https://github.com/RoboDurden/Split_Hoverboard_SimpleFOC/blob/main/include/PilotI2c.h Here with the C firmware, this is not possible.
Users already request PWM and ADC control :-( All three files share the same function definitions so there is no more need for stupid The If you understand the idea, i would be happy if you would change your code because i can not test it. Ideas welcome. |
Nope not hidden, middle of the image, there is quite a bit of compression but mainly the receiver module is just tiny! I think it would help to give your link mode a name since UART is very close to USART... arduinoLink, arduino, command, commandLink I did look into it but I'm not sure about the intricacies in adding files, hence why I tacked it on. Making the all three files share the same function definitions means only one can be used, so no mixing and matching adc, uart, pwm for the speed and steer. I do agree with moving the CRSF to a different file, same for adc, pwm, test (treat test like an input source) Maybe just have some proxy functions in
DMA calls
Main calls
Then main calls
In |
commsSteeringCRSF.h Could also have proxies for telemetry. Maybe make a /inputs directory in /src for all the input type files. |
Okay i will do the design changes. But not today. When if have made the design change to allow different controllers/pilots (always only one so no mixing) it would be great if you make a youtube video tutorial on which parts to buy to use your controll method :-) What do you think of my idea to name these different controllers "pilots" ? |
I am looking at the inputs as devices rather than the person. So using maybe an encoder device via an arduino for a steering wheel while using an adc device input for a throttle, and having the option to connect a pwm rc remote with an override switch for remote control. So I think pilots would be to restrictive of a concept. I think people's use could cases vary a lot from just a speed and steering input. For example alongside the remote input I am going to have a autonomous controller loop with a camera so the wheel speed will be controlled 1 to 1 so the kinematics can be calculated for the control. For the crsf I can make a video, it is quite simple, just a reciver 4 wires and the controller. What is that aim of abstraction to "controllers", rather than keeping it simply a data stream? |
Well i really love object orientend programming, one of the most important inventions of last century. More important than the invention of the car or the atomic bomb ! But for more complex situations (like vision control), we need an additional ESP32 anyway ? Maybe "operator" would also work. So introducing the concept of a pilot should make it easier to understand where functionality belongs.. |
But in the instance of a vehicle like a hoverboard the pilot is the person/machine vision not the interface between them. The pilot is the thing that tells the Arduino to send a command to the hoverboard, the way that command gets there is just an interface. Looking at the uart as the pilot would be like limiting a helicopter to thinking the cyclic is the pilot and so it is only able to acknowledge the input of the cyclic (the one and only pilot) disregarding the other "pilots" such as the throttle, pedals, collective.... it wouldn't work. That is why I am suggesting |
Of course, the Arduino code could also have its own Pilot class that implements the vision control and sends speed steer commands to the hoverboard. I aggree that there should be a third class in between the uart and the motor: Receiver (uart) -> Pilot (data to speed/steer or speedL/speedR) -> Motors. So Receiver -> Pilot -> Motor is not that easy to implement. Problem with "receiver" also is, that commsSteering does not only receive but also transmits data back to the Arduino. So i prefer to think of that receiver als the pilot and do not care who is piloting the pilot from the Arduino/Esp32/RC-Control/etc. The pilot is the one who comes up with the speed/steer values. |
My problem is that today i also succeeded with the I2C implementation in the SimpleFOC firmware: Candas1/Split_Hoverboard_SimpleFOC#11 (comment) |
What hardware does simpleFoc need that isn't the 64kb MCU? I have got some simpleFOCMini that I am yet to use on a fast processor, I have made a custom foc controller / sine closed loop controller with gimbal motor and 3half bridges but it needs more voltage to overcome cogging. Hopefully soon I too will have a good idea on how simpleFOC works, through that project. I really don't think it needs to be c++ due to the lack of instancing. |
The layouts with a GD32130C6 MCU only have 32 kB. Our SimpleFOC firmware currently needs 43764 bytes :-( |
Oh, I misread, you mean the foc firmware will run on 64kb... so the Gen2.x will have no use. |
I look forward to testing it... hopefully it should help tight the path following control loop I intend to get working. |
WizzardDr what is your YouTube channel? I am interested in the video you mentioned that you could make. |
https://cdn.discordapp.com/attachments/596350022191415320/1153628310895599647/VID_20230919_104329.mp4
I added a USART decode mode and made them dependent on
USART_CRSF
orUSART_SERIAL
.