Like I said in our last chat the #IFDEF sure has its con and pros, especially when it comes to readability. but at some point it might be hard to avoid. Keeping them to a minimum sounds like a good thing.
I vote for removing the old command set. But this will exclude all owners of the old V1 SSC-32 boards, if there are any leftā¦
Personally I prefer the 3/4 DOF support in the same code. But Quad support should be a different project, like biped support.
Iām willing to let the offsets go if Mike solve the GP bugā¦
The large offsets can be solved using the āsnap hornā method and an additional offset in the code. This mean Iāve to recalibrate my T-Hex .
If you use the LiPo for powering both electronics and servos youāve to measure the VL. But yes, the main function is to turn off the hex when voltage drop to a certain level.
If the normal/binary command must be supported (and also the servooffsets) one solution could be a ServoDriver file in the project, like we do for the controller. That would make the code much easier to read. Is that doable?
I totally agree with you about the readability of code is of great importance! But I also think having a different code base for each different configuration would also be difficult to a continue to evolve the code base for all of the 3 and 4 DOF Hex robots that Lynxmotion sells. This is why I personally think we should aim toward one code base for both 3 and 4 DOF T-Hexs. I also personally believe that we will want to evolve this such that not all of the legs are the same, as when we look at spiders and the like not all of their legs have the same length of joints. That is why I tried to add the Per leg config config code. I am sure we could do all of the 3/4/per without #ifdef, that is we could generalize to per leg config, Where in the 4DOF mode all of the values are the same for each leg. Likewise for the 3 DOF version, with the addition that for the one joint, you could either define as some fixed value (maybe 0) and with the Min/Max angles defined as the sameā¦ The issue here is you would probably be taking a slight code/speed hit to generalize it this way.
I also vote for Binary mode. If the user has an old SSC-32, they can always order a new chip for it. This will probably only impact some older CHR-3 type robots that are several years old. Another option: split the SSC-32 code out of the main file into a Servo Drivers module, that is included as part of the project (This also would include the interface to running sequences). Then generate two versions of this, one for Binary the other for Ascii. Actually you could then generate a 3rd version for Arc32 which uses HSERVO2 support and rolls itās own sequences code. This is how my Phoenix works! (i.e. - it would be great to roll my Arc32 phoenix version into this as well)
Note: I did something like this with my port to spin (propeller), I created an object to handle the SSC-32, I also developed a version that the servos were controlled directly by the propeller. Note: I only tested the second version with one leg as I did not wish to tear apart one of the robots to do this and I only had enough spare hardware to build one legā¦
I agree with simply using the SSC-32 offsetsā¦ On the Arc32 code, I store them in EEPROM and have code that reads it in and also additional code that allows you to update themā¦
1.) We will stick with the Binary mode for now. If someone wants to use the ānormalā command set it is still a matter of copy, pasting 2 functions in to the new version. Jim, are you fine with this?
6.) Ok, we keep the source general for both 3DOF and 4DOF. Different number of legs will have a different source.
7.) Finally I talked you out of code offsets Zenta 8). Offsets will be removed from the list.
10.) New point, have separate length configurations for each of the legs. This will allow to build a hexapod using different legs. This will not be optional though, just add the same numbers if the same legs are used.
LOL, how about a sound recording?
Maybe this weekendā¦
Iāve got a a few questions:
I decided to use the constants to allow a single point of configuration for all servos. Removing the calculation and make is fixed to 10 like you described a few posts before doesnāt seems right. Now it can be adjusted when we use other servos with different a PWM / deg value. I think that leaving out the calculation doesnāt give us much of a performance win to. Are you fine with this?
Reading the voltage of an analog pin is pretty easy. This little test program reads the input of AX1, VL (input 17)
BattVoltage var word
main:
adin 17, BattVoltage ; Battery voltage
BattVoltage = (BattVoltage*1955)/1000
serout s_out, i38400, [dec BattVoltage,13]
pause 1000
goto main
Iām surprised that the value isnāt absolutely stable. I added a voltage of 6.04V using a net adapter. The readout was between 6.03V and 6.15V which makes a difference of 0.12V. Do you know what the working voltage and turnoff voltage of your lipo is? (I always reload the lipo of only 1 of the 2 red leds on the UBEC are on)
If it is accurate enough I will implement it. Otherwise we could also use an array and calculate the average of a few reads. But this adds more overheadā¦
As you know Iāve just answered this in our last chat.
Keeping the constants for pwm calcs is the best way.
As soon as the LiPo voltage reaches a predefined level the LiPo safety gets triggered so that you wonāt be able to run the robot any more. Thats the most important part. Iām using 6v as a trigger level on my PolyQuest LiPoās. Using about 6,3v would be even safer for all brands.
Earlier I converted my code from TImerW to TimerAā¦ Probably not that important, but I was able to reduce the number of interrupts per second. But I had to add a multiplier and divisor to to convert the clock ticks to milliseconds.
1a) I have had a few occasions when a leg would act funny or jerk a little randomly, and found that if the timer interrupt happened while doing serouts to the SSC it could corrupt the output, especially at faster baud rates. So my versions have a set of disable/enable Timer interrupts that bracket the serouts to SSC. (I set which interrupt I am using as a constant as it changes for Bap28 versus Bap40/Arc32). With Timer A you only have about 7 or 8 interrupts per second, so wonāt lose interrupt during the serout code.
1b) Some input controllers like XBEE may use interrupts (directly or indirectly through hardware serial port). So I also added call outs to the Control code that said, disable your interrupts now/ It is OK for you to Enable them again.
Added: On some robots, that I use the pS2, I also have an XBEE on P14-P15 so I need to move the PS2 to another set of pins. At least half the time on Bap28 and Lynxmotion PS2 remotes the internal pull-up resistor on the Basic Atom Pro is sufficient for the Dat line. This works for P0 and P16, which on the Bot Board 2 is the only reasonable locations to start a group of 4 pinsā¦ (P4 does not work as P6 and P7 have lower voltage and did not work. P8 does not work as P9 is used by the speakerā¦ But if needed could probably use the pull-up on that pin as wellā¦
So in my PS2 code I start the InitController like:
[code];[InitController] Initialize the PS2 controller
InitController: #if PS2DAT = 0
PUCR5.bit0 = 1 ; Note these pull-ups may not be sufficient for all PS2 remotes. #endif #if PS2DAT = 16
PUCR1.bit1 = 0x1 ; 16 is on H8 P11 which has a pull-up #endif
high PS2CLK
ā¦[/code]
Added Maybe? Recent Zentas (with a little help) enhancements to running GP Player. Again XBee code needs to disable interrupts during the issuing of commands and query back from the SSC-32. (Also needed a slight pause). But in addition to this there were call backs added to this code to the controller code such that the it could give additional feedback to the user. Also it allowed the controller to update the running of the sequence.
Along this same line, my versions have some places where the main code may tell the control code about some events, which allows the code to inform the user or the like. My additions may not have been generic enough in that it said XBee Play a soundā¦ But this could be updated to be something like: ControlEventCallBack[EVENT]: Where we could define a set of events like (low power shut down ā¦)
Thanks for the feedback! Some of the points are new to me so you need to fill me in a little bit. I would be happy to discuss them with you.
Does the rather slower TimerA has an high enough resolution to sync both BAP and SSC? I think it is a good thing to reduce the amount of interrupts. Can you provide me an adjusted version of the alpha release with this new timer?
Iāve seen the enables/disables but I wanāt really sure what they where doing there. So I commented them out. I will uncomment them.
Isnāt it a better solution to disable/enable ALL interrupts when going in to critical sections like updating the SSC? This way we donāt need to add code in the ācoreā file which is only used when the bot is controlled by XBEE.
I think youāre a one of a kind guy, having 2 remotes on one bot!
No serious. Most of the time I use my DIY remote while programming / testing. Once the software is ready I simply swap receivers and try the PS2 remote. This should be good for debugging / testing but I doubt this has any value for most of the users. But please, let me know if Iām on the wrong track here
Isnāt it possible to have the feedback from the bot to the remote defined in the XBEE file? The idea sounds very interesting. Having a predefined set of events that can be used to transfer information from one part of the code to the other. Iām totally in to this but I think itās a good idea to split this idea into a new topic and work this further out. In the mean while we should get our TA base version (v2.1) ready. I think the event stuff should be added later on since we still need to test the ideaā¦
Thanks for the input and let me know what you think!
Hi Xan,
Quick first answer will get into more later:
1a) TimerA - with division 8192 gives us a resolution of .512ms, which for any of our code I think is accurate enough. Will give you updated code.
1b) On XBee we do not disable interrupts, that would cause data loss, what I do instead is to change the RTS line coming from the XBee to say donāt send me any more data. I could imagine other controllers like Bluetooth or serial or the like might need the sameā¦
Not sure, how many out there may have other uses for their hardware serial portā¦ But I agree it is probably a minority of us. But for example I have in the past used the HSEROUT to talk to serial LCD displayā¦
Two parts - The current GPPlayer code is self contained, you start it and never get a chance to interact, until it completes. So if we want this functionality we will need some callback or the code reconfigured such that it calls ControlInput and ControlInput checks state orā¦ May not be able to report anything with PS2, but could maybe allow user to manipulate the sequenceā¦
Other feedbacks may be able to be deduced by ControlInput. Like you shutdown the robot due to low power. Might be variables that can be used or the like. Not sure about others, like with TA type code, where this code will live and what feedback can be or should be given back to the userā¦ We will see as we go.
The resolution is more then enough. The less interrupts the better. Thanks for this good update!
Clear! Iāll return the āshut up!ā command
If it it ok by you, we will leave it for nowā¦
In the current way the GP player works we did not had to read the control inputs since we couldnāt interact with the GP player. But with the upgrade Zenta did it is getting a big change anyway. I will wait unit youāve got it tested.
Quick question for you. Is it possible to use this code on an arc-32? I am thinking it should run with little modification since the arc-32 is BAP based but I wanted to ask to be sure. I do have an ssc32 as well, so really the arc would just replace the botboard and to start I would still use the ssc32 for servo sequencing.
I just want to know if I can get it working like that so I can play around with it and learnā¦ then maybe migrate the ssc32 functions to the arc32 at some later time.
If you look at the Beta version 2.1 thread: viewtopic.php?f=8&t=7658 you will find code for the Arc32 without an SSC-32. To help keep things cleaner and remove some #ifdef type code, we removed the Arc32 (with SSC-32) or Bap40 support from the code. It is not hard to add back in. In fact my local machine has such fileā¦
This file replaces the file by the same name in the different zip files I uploaded on the thread I mentioned aboveā¦
Ahh, okay, I was counting on having to do that myself, but this is better. Thanks. I was more worried about something like the clock speed differences causing a problem, but I guess not. Thanks for the help.
Yep, the different processor does make a difference. In that on the Bap28 it uses TimerA of the underlying H8 processor, but on the Arc32 (or Bap40), it does not have TimerA. It was replaced with TimerB1. The main place that depends on the speed differences is the timing code and there are different multiply/divide constants to convert the ticks into millisecondsā¦
.
