Closed AbBaSaMo closed 2 months ago
@AnthonyZhOon this is a milestone 2 task but moving it to 'in progress' as https://github.com/Monash-Connected-Autonomous-Vehicle/ESDA/issues/7 is in testing/review phase and other tasks cannot be worked on by will/jiawei due to all ready being assigned or blocked by something
elec lead said this usb to can device is good to go with but we need to purchase it before the latter tasks of this issue can be worked on https://core-electronics.com.au/usb-to-can-adapter-model-a-stm32-chip-solution-multiple-working-modes-multi-system-compatible.html
I might do so next week but will update if otherwise
I've managed to get the node up and running that subscribes to the topic cmd_vel and display only the linear.x msg of the cmd_vel twist message.
As a note for myself, when adding a new node to the esda_control package, you have to make a new python executable in the package folder, and once that is complete, go into the setup.py and add a line to the "entry_points" console scripts and update it there to work with ros2 run
. It dosen't stop there as we have to update the launch file as well to start up the new node.
Not entirely sure how to convert it to the CAN message, apart from the link Jiawei sent me. Does anyone from @Monash-Connected-Autonomous-Vehicle/avp-team know what I can use for the CAN messages bit? Also either walk me through or suggest some reading material to look through. Thanks
@Jokua nice, push to the repo on the same (esda-control) branch and make sure you pull before each push cause I'm making some changes to the launch file.
Dw about the CAN stuff atm cause we're waiting for our usb to can device to come before we look into requirements for using it such as suitable packages etc.
@Jokua nm actually, if you want, you can look into how to send messages to this device https://core-electronics.com.au/usb-to-can-adapter-model-a-stm32-chip-solution-multiple-working-modes-multi-system-compatible.html?gad_source=1&gclid=EAIaIQobChMIpfiu-bC2hAMVH6lmAh2XDglYEAQYASABEgK0Q_D_BwE in the appropriate can format we discussed with Jai and Callum, since this is the device we'll be using. We just can't test things until it gets here.
ok, i've pulled first to make sure there's nothing updated yet, and i've just pushed my changes @AbBaSaMo
ok, i'll take a look
Small update to the node and clarifying instructions added
So we aren't making a publisher, but we're connecting to a serial device, then whenever we get a linear vel, we convert it to a can msg and send it via that serial device i.e. the one I linked above.
I've added code for connecting to serial (although not sure on what serial port and baud rate to use) and creating and writing CAN message. Not sure what is meant by the note on line 24.
I think default baud is 2000000 as stated by the website linked above?
Also please have a look at it because I'm not too sure if its correct.
What's meant is that we send 2 separate commands for the 2 wheels: 1 for left wheel, 1 for right wheel e.g.
cmd_vel says go at 9m/s, we tell left wheel go 9m/s and then send a 2nd command at the same time to right wheel telling it to go 9m/s
@Jiawei-Liao am getting this error launching the control module
had you encountered this? also is it appropriate to use given we're using a custom can msgs design? my impression was that we just create a binary var and set the different bytes in accordance with the design callum and jai went over
Tried adding ros_canopen as well as ros2_canopen to package.xml but rosdep install cannot find the packages even after apt-get update @Jiawei-Liao if it's needed to use this package we'll have to add the repo as a submodule else use something else.
Totally forgot we were using custom messages so maybe it’s not needed. If it’s not working, would it be possible to just copy and paste the frame message?
Wdym by copy paste the frame message?
Like just copying the message into the folder
For the custom can message, where was that image for its layout? And did you want it to be implemented here or some other folder?
@dylan-gonzalez just confirming as long as we have a binary var with the following structure, we're good to go and just need to send it via serial. So e.g. we send the bits 01 000001 0000110... @dylan-gonzalez just confirming. representing a command over serial to the usb-to-can converter and the converter will do the rest without needing to use any can libraries?
@Jiawei-Liao adding link to the notion with the layout to the issue description
im not sure what converter you're using... probably a question for the elec team
@Jiawei-Liao @Jokua keep in mind the servo is using USB0 so when we connect to serial for this device, we can't use the same thing
Do we know if it'll be on another one like USB1 or something? But I'll keep that in mind to change it after tomorrow's meeting
I think sending floats mostly works. Although not sure why there is a small difference in the received data and transmitted data. Maybe there is too much precision in the send data?
This is code on the CAN bus/Arduino side. I have given it 8 bytes of buffer which should be able to store a float64? So I'm not sure how to fix this rounding error.
looks like it is missing bits near the last place, sign, exponent and leading mantissa are the same due to cutoff. You might need more than exactly 8 bytes of buffer due to length encoding, try printing the raw bytes on both sides to see?
On Thu, 7 Mar 2024, 9:35 am Jiawei, @.***> wrote:
I think sending floats mostly works. Although not sure why there is a small difference in the received data and transmitted data. Maybe there is too much precision in the send data?
image.png (view on web) https://github.com/Monash-Connected-Autonomous-Vehicle/ESDA/assets/105030837/9c6febbc-ff46-46b8-bcc2-422f64d9fc84
image.png (view on web) https://github.com/Monash-Connected-Autonomous-Vehicle/ESDA/assets/105030837/637f5059-072d-4dc8-b7c0-917ce7d42469
This is code on the CAN bus/Arduino side. I have given it 8 bytes of buffer which should be able to store a float64? So I'm not sure how to fix this rounding error.
image.png (view on web) https://github.com/Monash-Connected-Autonomous-Vehicle/ESDA/assets/105030837/6112465f-85e1-42ea-aba9-80bb4f5743af
— Reply to this email directly, view it on GitHub https://github.com/Monash-Connected-Autonomous-Vehicle/ESDA/issues/5#issuecomment-1981971966, or unsubscribe https://github.com/notifications/unsubscribe-auth/A6G6POTZG3A7UKKF724Q6WTYW6K2BAVCNFSM6AAAAABBRHQSSKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBRHE3TCOJWGY . You are receiving this because you were mentioned.Message ID: @.***>
I changed it to double from single so that it can take a larger precision now. Printing out the bytes and value to 12 dp on both sides shows the same values. I think the extra decimal places is just a limitation of floats and doubles.
@Jokua @Jiawei-Liao
What is the state of this code and its branch? Is it fully complete? Last I remember we wanted to test it. I want to know if it can be merged or not.
I made a final commit to allow sending messages using the correct IDs for left and right wheels. I accidentally added some zed camera commits to this branch as well. But I think they'll be overwritten once the zed camera branch is merged. I'm not sure if it has been added to control launch py. Not sure where that is located
Other than that, it can be merged now.
How do I merge this branch?
@Jiawei-Liao what time are you in tomorrow? we'll do it then and have a quick code review
yep I'm here now
marking as closed, testing will ne new issue
Refer to the following docs https://control.ros.org/humble/doc/ros2_control/hardware_interface/doc/writing_new_hardware_component.html
https://www.notion.so/monashcav/ESDA-CAN-interface-7a713ff78ae04d2691eaa09ee0847c14