Rename folders for clarity [AEK-269] #36
Conversation
aliphys
changed the title
|
|
| @@ -46,7 +46,7 @@ void setup() { | |||
| // This way, you can program the motor to reach a certain position or velocity without any further intervention. | |||
| // The PID can be carefully tuned if a particular profile is needed. | |||
| pid1.setControlMode(CL_POSITION); | |||
| pid1.setGains(25, 0, 3); | |||
| pid1.setGains(25.0f, 0.0f, 3.0f); | |||
|
Memory usage change @ cb2af4b
Click for full report table
Click for full report CSV |
|
@Rocketct can you please help me change the required files required for the GitHub Action? I am learning GitHub actions as we go along. 😃 |
|
https://github.com/arduino-libraries/ArduinoMotorCarrier/tree/master/examples check the names here as you can see here the folder name are MKR and Nano, in your PR you changed the name in the github action as examples/NanoMotorCarrier and examples/MKRMotorCarrier you can do two action:
one think @aliphys , did you discused these changes with @ErnestoELC ? |
|
@aliphys please double check apparently that commit was not merged, or is not present on master, make that changes and add it to this PR. but first of all talk with @ErnestoELC this repository cannot be modified so lightly as the others, second and important point because we are using an implicit cast can you and @ErnestoELC check if works or not, because could happen stranger things so we shall be sure that is working properly. |
|
@Rocketct just spoke with MW, changing the |
|
okk perfect so make the changes on the folders name and after the test could be merged |
|
ah okk looks like you have made it let me check if the github action pass |
|
@per1234 ciao Per can you check the github action? it fails when start to compile the examples |
|
@Rocketct everything looks as expected to me. There are some compilations that fail, but those are true results. You will see some of these if you look in the logs: The failure of the "Compiling previous version of sketch to determine memory usage change" compilation is normal and expected in this case where the sketch did not exist at that path in the PR's base ref. This second compilation is only done for the sake of the memory usage change report, which is purely informational. The failure of that compilation does not change the CI result. It will start working fine on the next PR after the sketches have been established at their new location. So focus only on the parts of the logs where the first compilation failed. Those are the ones that cause the ❌ . Note also that there were widespread sporadic GitHub Actions outages all day. My email inbox is full of notifications of spurious workflow failures. These were transient so they were usually passing after I re-ran the jobs. The results you see from this PR are from days ago, before that happened, but if you tried running the CI today then you might have encountered some of these failures. GitHub Actions seems to be increasingly unreliable lately, but at least they get it back up to normal fairly quickly. |
|
@per1234 ah ok i though that these ones: was fails, so fine i think that we should focus on portenta's one, but i think that there is a mistake because as far as i remember this library should not be compatible with portenta, can you confirm @aliphys @ErnestoELC ? |
|
@per1234 I appreciate your explanation of the GH actions. 👍 @Rocketct Neither boards are compatible with the Portenta, with no plan to provide compatibility in the near future. The Motor Carrier library is designed to work with the Nano 33 IoT (for the Nano Motor Carrier examples) and all the MKR boards (for the MKR Motor Carrier). You can see the list of compatible boards on their relevant docs pages. Note: Nano BLE 33 Sense compatibility is experimental at the moment. |
|
I'm the one who added the compilation for Portenta H7 to the CI workflow. The reason is because this statement:
implied to me that the MKR form factor accessories are intended to be compatible with the Portenta. If the hardware is intended to be compatible then I would expect the software to be compatible as well. |
|
@per1234 ah ok mmm for this particular case should not or better was not implemented the software support to this shield and i don't think we want it, but if mandatory we could see how to implement it |
|
Well, I had to make some educated guesses as to which boards a library was intended to support when it came to setting up the compilation workflows. The point of the workflow is to find example/board combos that don't compile, so I couldn't use a failure to compile as an indication that a board should not be compiled for. In cases where the CI is configured to compile for a board when there is no intention of the library supporting that board, I'm always happy to correct the CI configuration. However, in that case I would also suggest the evaluation of whether the supported boards can be more clearly communicated to the user, since if it was unclear to me then it might well be unclear to others. |
|
the portenta and the shield are hw incompatible |
|
PR submitted to remove the Portenta compilations from the CI workflow: #39 |
@Rocketct can you kindly clarify why they are HW incompatible? The Portenta does have all the pins for the MKR boards. |
|
A1 and A2 cannot be used as analog out and they are used to controls motors through the shield, so the shield and the Portenta cannot be used together. |
|
@Rocketct I have taken a look at the schematic. A1 and A2 pass through the bidirection voltage translator and then connect to IN2 and IN4 respectively. How does the lack of PWM influence the ADC capacilities? |
|
are two different things, however in this case the problem is that from A0 to A4 are connected to a switch (analog switch) that allows to choose if use this pin as PXY_C or PXY, really the incompatibility born in the exactly moment when you decide to use the SPI, that i notice is not populated so there could be a chance to make it usable, but in general if you use alone the pins only as a pure analog there shouldn't be any problem, but if you use PXY and meanwhile you want to use PXY_C functionality this is not possible, because from an hw point of view you are allowed to use only one pad at time. |
|
@Rocketct If we use the labelled pins only for analog input (i.e. use the ADC), then there shouldn't be a HW blocker for using the Portenta with the MKR Motor Carrier, is this correct? |
|
no @aliphys that pin is conneted to sig INX pin, but AFAIK that connector is used to connect motors too rigth? if yes the sig signal shall send some signal to control the motor than analog out. |
|
The INX (IN1-IN4) connectors are designated as analog inputs (so the user can attach external sensors) and not used to control the motors. |
|
ok so this means that the problem doesn't exist |
|
That is great @Rocketct 😃 . |
|
i no have idea, but before this we want that is compatible? what saw the project owner? have sense make it compatible? |
per1234
added
type: enhancement
No description provided.